2008年12月31日水曜日

多重起動4

どうやらPHP上でexecで呼び出すとプロセスを別に生成するらしい。
だから今まで書いたようなプロセス増えすぎ現象はそれで理解できる。

別の方法で呼び出す方法もあるが、プロセス数は一定に増えるので多重起動時のプロセス数を増えるプロセスのn倍にすれば解決する。
できれば1プロセスにしたいところだが、バイナリが変わってもシステム自体を大きく変えない限り大きな問題にはならないからそれで行くことにする。

2008年12月26日金曜日

多重起動3

停電中で落としていたサーバーも無事復旧したので多重起動を実装してみることに。
サンプルを作ってとりあえず動作確認もすませ、実装してみる。

思うように動きません・・。

とりあえずサンプルの時点で

$check = exec("ps -ef | grep -c binary_name");

をしてやると$checkが2になるのはわかっていた。1つはgrep自信でもう1つは謎だったが、とりあえず-2してやることに。

普通に動かしてみて、

$check = exec("ps -ef | grep -c binary_name") - 2;

の値を確認すると

$check=5

増えすぎです。

同時にもう一つ動かしてみると・・。

$check=5

変わりません。せめて増えてくれ。

2008年12月23日火曜日

多重起動2

結局多重起動は簡単な対策で取れることが判明。

ps -ef |grep -c binary_name

で実行数が分かるのでそれで個数制限すればいいだけでした。
最初からなぜこれに気づかなかったのだろうか。

2008年12月21日日曜日

多重起動

多重起動防止にファイルを使おうという話が出ていた。

1,実行数を書くファイルを用意する
2,実行したときにそのファイルを読み込み、一定数以下なら実行して実行数をインクリメント
3,実行後デクリメントして再びファイルに書き込む


一見これで動くように思うが、落ち着いて家に帰って考えてみると実行中にブラウザを閉じると値が増えたままになってしまいそのうち動かなくなる。
やはり、落ち着いてジョブマネージャ等を使うのがいいのだろう。

2008年12月20日土曜日

HTMLのdisabled

disabled属性が微妙。
ShortestPathの方でも当初は使う方向で進めていたがブラウザによって挙動が違うので避けていた。

SDPAオンラインソルバーの方でCPU数を指定するときに使っていて、その初期値がおかしくなっていたので修正。そのついでにちょっとソースを色々と細かく見てみるとこれって動いたっけ?
と思い色々なブラウザで挙動をチェック。

Firefox:正常動作
IE8:動かない
Chrome:動かない
Safari:動かない
Opera:正常動作

となった。こうしてみてもFirefoxの安定性は高い。一番規格に準拠しているのもFirefoxらしい。
ちなみにIEは規格を無視して独自規格で同じような機能をつけている。

disabled属性という単純なモノでもここまで差が出るので恐ろしい。
disabled属性よりは、hidden属性の方が安定している気がするのでそちらですむならそちらを使用した方が良い気がする。
また、disabled属性が動作しないというわけではなくdisabled属性のJavascriptによる変更ができないといった方が状況としては正しい。

2008年12月19日金曜日

オンラインソルバーの将来性

オンラインソルバーも基本機能はそろってきていると思う。対応できる問題が少ないというのが根本的な問題ではあるが。

ここまでくると、ユーザー側の使いやすさをもっと考える時期でもあると思う。
Ajaxを利用するなどと言うとさすがに無責任か。
AdobeのFlexなどを用いるのもありだと思う。見た目だけでなく色々な機能を比較的手軽に利用できる。
とはいえ、きちんと覚えるには1ヶ月くらいはかかってしまいそうなのでリスクも大きい。

学生証を添付すればAdobe Flex Builder 3が無償で手にはいるとのこと。
統合開発環境はなかなか手に入らないので、こういうのをやってみる人がいても良いとは思う。
興味がある人がいればの話ではあるが。
(https://freeriatools.adobe.com/flex/)

2008年12月18日木曜日

保守4

新関数を作るという話が出ている。
グラフなりグラフIDなりを引数として、そのグラフに対応する四隅の座標を返すというもの。
今まであまりこういう関数は使ってないが使う用途は色々出てきてもおかしくないし作っておいても損はないかと思う。基本的な機能であるし。

2008年12月17日水曜日

保守3

基本的に保守作業のほとんどは終えている。
これで、新バイナリにも対応できるので少し速くなることも期待できる。
とはいえ、計算速度よりも描画速度等の方がネックなので体感は変わらないかもしれない。

今まで正規化されていた座標を元の緯度経度に近い形(緯度経度を1e+6倍したもの)にした。
Dimacsで使われているデータ通りにしたというとわかる人にはわかりやすいかもしれない。

2008年12月14日日曜日

Google Maps Hacks

オライリーの本です。

今まで、この本に限らずGoogleMapsに関する本はあまり読んだことがなかった。
ShortestPathに使えるかは別として違う視点から見られるのは面白い。

マーカーを減らすのにも非常に面白い手法を用いている。
知らない機能はほとんどなかったが、使い方一つでこういうことも可能なのかと思わされることもある。
Ajax自体がそもそもそういうモノだったりもするのだが・・・。

2008年12月13日土曜日

保守2

今回の保守作業の目的はただのバックアップだけではなく誰でも管理しやすいようにするというものも含まれている。
そのため、ディレクトリの変更等を行っている。
ディレクトリの分け方は入力と出力で決まることになる。
そのほかは大きな変更はない。

2008年12月12日金曜日

保守

現サーバーが落ちてもすぐに復旧できるようにしている。
バックアップのサーバーでShortest Path Online Solverを動かすのが目的。

先日書いたとおり少々移行に時間がかかっているものの大半は終わっている。
またこの移行作業をきっかけに、バイナリを最新のバージョンに変える予定のようだ。

今までIE8で動かなかったものも原因はわからないが、なぜか動くようになっている点も注目できる。
結局は変数の受け渡しがうまくいってなかっただけなのかもしれない。変更している点はそこだけなので。

2008年12月3日水曜日

トラブル

動かない理由としては変数の受け渡しがうまくいかず、$POSTで渡していたものをすべて$GETにすることにした。
あまり良い対策とはいえないが、文字列チェックは内部でしているので大きな問題になることはないと思われる。
とりあえず初期バージョン辺りはなんとか動かすことができている。

全体として変数関連が問題なので面倒だが全ファイルそういう作業にすることになる。

2008年12月2日火曜日

バックアップ

現在Shortest Path Online Solverのメインのマシンと、バックアップのサーバーとしてもう1つ用意しようとしている。

OSも同じだし、コピーすればすぐ動くだろうと楽観視していたらそういうわけにも行かなかった。
色々と問題が発生しているので少し時間がかかるかもしれない。

ついでの作業

別のサーバーでも動かすために、マシン名、ドメイン名などを変数化している。
こうすれば、マシンが別の環境に移動しても新しいサーバーで動かすにしても変数1つ変えるだけで良いので移行作業が楽になるだろう。

2008年11月27日木曜日

健康診断

入社前に健康診断をしろということなので健康診断に行ってきた。

まだ20台だし、そんな問題は無いだろうと思ったら・・。

血圧が高すぎました。

今日から食生活を考えてみようと思います。

来年度から食生活改善ブログになったりして。

2008年11月26日水曜日

最適化オンラインソルバー

最短路だけではなく、様々な最適化問題用オンラインソルバーの仕様について以前行った作業があまりまとめられてないのでまとめてみる。

・基本は現在のSDPAオンラインソルバー

入出力はほとんどの場合、テキストファイルによる入出力であるため、変数化して、追加作業が楽なようにする。

現時点で、タイトルや結果をメールで送るときの文面をのぞいては、ほとんど作業が終わっている。

solver/common_data.php

にソルバーのディレクトリと表示されるタイトルを書く。

solver/ にそのディレクトリを作り中にstatus.phpを書く。

これで、メインページにはそのソルバーが追加され、ファイルのアップロード等もできる。
パラメータファイル等の記述もあるため、それらの心配もすることはない。

あとはexecute.phpのページに実行のコマンドを書く必要がある。ここもなんとか共通化したい。

2008年11月24日月曜日

各バージョン

shortest path online solverも当初に比べて、色々な種類が出た。

個人的には、経由点指定バージョンとKMLバージョンがおすすめである。
viaバージョンは当然だがP2Pバージョンと同じ結果を出すことができる。(地図データによって計算に時間差はでるが)

また、KMLバージョンはダウンロードしてしまえばオフラインでできるということ。また、GoogleEarthは快適に動くので操作する上でも見やすい。
しかし、それらをあわせたKMLの経由点バージョンは様々な理由があり、まだ出ていない。

2008年11月23日日曜日

経由点バージョンその15

先日の通り、Operaでは右クリックできない。(設定を変えればできるかはユーザーではないので不明)

そこでOperaでは別処理として、最後のマーカーを削除するボタンをつけた。
これですべてのブラウザで最低限の機能は出そろった。

2008年11月22日土曜日

経由点バージョンその14

思っていたより時間がかかってしまったようだが、無事削除機能を備えた経由点バージョンも公開された。(正確には更新か・・。)

バグというバグは見つからなかったが使ってるマシンのIEがおかしかったため、各ブラウザの動作確認が遅れてしまったのが原因。

ブラウザによる問題は色々経験しているが、IEで起こるトラブルだけは原因不明で対処のしようがないから困る。

また、Operaでは右クリックで画像を表示とかのダイアログが出てしまう。
これは本家Google Mapsでもなってしまうのでこちらでは対応しにくい。

やはり無難に推奨ブラウザであるFirefox,Safari,Google Chrome辺りを使ってもらいたいというのが希望。

2008年11月21日金曜日

経由点バージョンその13

苦戦するかと思われていた処理もあっさり。


・消すマーカーがどのマーカーかをループで判定する。
・値をずらす
・マーカーの再作成
・マーカー数を1減らす
・終了

特にバグがなければこのまま公開になりそうだ。

2008年11月20日木曜日

経由点バージョンその12

マーカーの番号変更の方法を考える。

マーカーのアイコンは、番号が上に振ってあるわけではなく、自分で1~10まで用意している。
すなわち、マーカーの番号を1個ずらすためには

・前のマーカーを移動する
・今あるマーカーを削除し、同じ場所に新しく作成し直す

のどちらかの操作が必要である。

後者の処理もそれほど負担がなかったのでそちらを採用することにした。

2008年11月19日水曜日

経由点バージョンその11

これがこのバージョンの大きな仕様では最後の作業。

取り急ぎ削除の対応をしたが、今回は削除のバージョンアップといったところ。
機能は以下のような感じ。


・右クリックでどのマーカーを削除しても良い。
・削除したマーカーより後ろのマーカーは番号が一つずれるのでマーカーの番号を変更する。
・それに対応する変数の値を全て1つずらす。

これで削除に関しては問題ないであろう。作業を進めるのみ。

2008年11月18日火曜日

経由点バージョンその10

経由点指定バージョンで
いつの間にか最後のマーカーを右クリックすると消せるようになっている。

1 -> 2 -> 3 -> 4

とあると4だけ消せる。2を消したければ 4 -> 3 -> 2 と順番に消さなければならない。

ちょっと不便な気もするが、通常のviaバージョンから全てクリアの機能を削除しているだけなので大幅機能ダウンではない。

気づいていない方もいるかもしれないが、この経由点指定バージョンではドラッグしてアメリカの外にマーカーを持って行くとドラッグ前の点に戻るようになっている。

ちなみに、通常のGoogleMaps版では変更なく消滅する。

2008年11月17日月曜日

Safari3.2

がでたらしいので、一応動作確認。
一通りやってみたけど全バージョンでとりあえず問題ない。

Safariは表示が綺麗で意外に速いので、推奨ブラウザの1つである。

ちなみに推奨ブラウザは
Firefox,Safari,Google Chromeの3つらしい。

どうしてもという方はOperaも対応ブラウザ。

IE8は何度も書いてるが動作が怪しすぎるのでShortest Path Graphicでの使用はやめた方がよい。

2008年11月16日日曜日

経由点バージョンその9

引き続き作業中。

最後においたマーカーを消す場合、

現在のマーカーの個数を1個減らす。
最後のマーカーの緯度経度を0にする。

で処理すれば問題はない。

最低限これだけの機能はつける予定。


途中のマーカーを削除したい場合どうするかは模索中。

2008年11月15日土曜日

経由点バージョンその8

経由点バージョンのマーカー削除の作業を行っている。

基本的には使われていない右クリックによる動作で実現する予定。

GoogleMapsのイベントでは、

GEvent.addListener(map,"singlerightclick",function(point,src,overlay)){

処理

}

で実現できる。
マーカーを右クリックするとoverlayが指定されるため、

map.removeOverlay(overlay);

とでもやればマーカーが消えるだけならなんの問題もない。

2008年11月14日金曜日

経由点バージョンその7

管理を楽にするために、経由点バージョンの最大点数の指定を変数化した。

これで、1カ所変えるだけで移行できるため、マシンの拡張等があってもすぐに対応できる。

当たり前と言えば当たり前の作業だが、意外に手間取ってしまった。

JavascriptでFormの配列を読み込むには

document.form1.elements['hoge[' + (i) + ']'].value

にしなければならないらしい・・。
やればやるほどJavascriptがわからなくなってくる。

あと、PHPとJavascriptの連携ってのは面倒です。。

2008年11月13日木曜日

経由点バージョンその6

計10点まで対応。

このくらいならさほど速度の差を感じずに実行できる。
これ以上増やす意味もあまりないのでとりあえず10点で固定しておくことにする。

あと、経由点バージョンに足りないのは点の削除くらいだろうか。

2008年11月12日水曜日

経由点バージョンその5

公開されている経由点バージョン。

実際に使ってみると、通常版とあまり速度の差を感じられない。
5点くらいなら問題ないということか。

ちなみにIE8では相変わらず表示されたり表示されなかったりする。

2008年11月11日火曜日

経由点バージョンその4

開発が進められていた入出力ともにGoogleMapsを用いた経由点バージョンが週末には公開されていたようだ。

先日書いたようなバグもそれに伴い修正されている。
どうやら今までのバージョンにも番号付きマーカーを利用するような設定にしたようだ。


新しいバージョンでは経由点を3個(すなわち合計5点まで)までしか指定できないのが残念なところ。
近いうちには10点くらいまでは対応するだろう。

2008年11月10日月曜日

経由点バージョンその3

出力だけGoogleMapsバージョンではfromEncoded機能を使っていなかった。
そこで、今回の機会でこちらも書き直すことに。


あれ?一部線が表示されていない。

おかしいと思って前のソースと見比べてみてもなんで正しく動くのかなぁと小一時間考えてしまった。

結局前のソースもおかしかったというオチ。

きちんと動いてたと思ってたんですが動いてなかったみたいです。

今までバグありのまま表示されてたようで早急に修正予定。

2008年11月9日日曜日

経由点バージョンその2

GoogleMapsで、番号付きマーカーを利用する方法は以下の通り。

1,番号付きマーカーのアイコンを準備する。
2,アイコン指定する。

これだけでよい。
念のためコマンドを書いておくと、

var num = 1;
var icon = new GIcon();
icon.image = "./marker" + num + ".png";
icon.shadow = "./shadow.png";
icon.iconSize = new GSize(20,34);
icon.shadowSize = new GSize(37,34);
icon.iconAnchor = new GPoint(10,34);
icon.infoWindowAnchor = new GPoint(10,0);

var newMarker = new GMarker(point,{icon:icon , draggable: true});

細かい説明は省くが、必要な値が入っていないと、ドラッグできなかったり表示できなかったりするので注意が必要。
特にドラッグが必要ない、影も必要なければ
icon.image
icon.iconSize
icon.iconAnchor
だけ指定すれば良い。(試してないですが)


番号付きマーカーの作成には
http://www.lumiere-couleur.com/pub/soft/markers/

のサイトが便利である。

2008年11月8日土曜日

経由点バージョン

経由点バージョンの開発が進んでいる。

通常の経由点バージョンでは

座標 -> 座標 -> 座標

となっているテキストをそのまま送って文解析していた。
GM版では、番号付きマーカーを利用して具体的な緯度経度は表示されないようになっている。

具体的に知りたい人は、マーカーをクリックすれば通常通り見ることができる。

2008年11月7日金曜日

ありそうでなかった

ありそうでなかったShortest Path Graphic GMの経由点指定バージョン。

コソコソと作り始めているらしい。

入力画面の変更が必要なため後回しにしてそのまま忘れ去られていたが、今思えばそんなに難しくはないので近いうちに公開予定とのこと。

2008年11月6日木曜日

Operaの修正

原因を一から探ってみると、
最短距離は表示されるが最短時間が表示されないことがわかった。

その辺に原因がある(Operaで読み込んでくれない)のだろうと推測し、ソースを書き直す。

色々事情があり、それぞれ独立させていたのだがこれを機に関数化してまとめてみたところ普通に動いた。
他のブラウザでも問題ないため、結果的に見ればソースが綺麗になってOperaも動くし良かった。

ちなみに相変わらずIE8では動かない。完全にIE8のバグで対応策も一応公開されてますが、面倒なので後回し。確認のため言っておくと、正式版のIE7では問題ない。また、IEでの実行は推奨していない。

2008年11月5日水曜日

Vine4.x

ちょっと話題がそれてVineの話。
日本語の表示が綺麗で動作も軽く、リモートアクセスで使う分にはなんの不自由もないVine。
別にVineにこだわってるわけではないが5.xの登場が待ち遠しい。予定が遅れてるらしく来年の頭になりそうな感じ。

Vine4.xではFirefox3に対応していなかったが、今は対応済。

apt-get install Firefox3

でインストールできるようだ。Firefox2との共存も問題ない。
どこかの会社が作ったOSドッキングブラウザみたいに前のバージョンが使えなくなることもないので心配ない。

Shortest path Graphicも試してみたがやはり3の方が圧倒的に早い。

仮想マシンのせいなのかOSのせいなのかブラウザのせいなのかはわからないが、WindowsのFirefox3の方が実行が早い気がする。

中のプログラムは速いのがいいが、オンラインソルバーのようなものは様々な状況が関わってくるので体感時間も重要視しなければならない。
最終描画まで同じ時間でも表示のタイミングを変えるだけで印象が大きく変わるのが怖いところ。

2008年11月4日火曜日

Opera

IE8の次はOperaも挙動がおかしい。

both表示の時にtimeの方が表示されない。こちらは原因究明中。
Encodedバージョンのせいだとは思うが、片方が表示されるだけに微妙。

IEは初心者ユーザーと、IEコンポーネントを利用したタブブラウザを使用してる人、Operaは根強いユーザーがいるだけに無視はできない。

IE7は問題ないからまだβ版な8の対応は後回しだが、そう遠くないうちには修正したい。

2008年11月3日月曜日

IE8その2

IE8はどうやら挙動が怪しい。

Firefoxとかでも同じ警告かどうかはわからないが原因不明の警告だけで表示は問題ない。
Chromeや、Safari等でも表示される。

IE7でも問題は起きない。というかIE7では警告すらされない。

そんな状況。


確かに善意だけのページではないので細かい警告すら許さないのも重要ではあるが。
0行目に警告があると言われてもどこにあるのかと逆に問い詰めたい気分。

2008年10月29日水曜日

IE8

ソースの整理をしていて、IE8で怪しい動作をするのにきづいてしまった。

結果画面でF5を押して更新すると何も表示されなくなることがある。
実行した後の結果では特に影響もないし何回かF5を押すと表示されるので、原因不明のため対策できない・・・。

2008年10月28日火曜日

簡単なこと

IE7で遅いならIE7だけ元のページにすればよかったという簡単な結論。

難しく考えすぎてました。
渡される変数の仕様はまったく変わらないので、IE7のときだけ元のページに飛ばすだけで良い。

IE7かどうかの判断はHTTP_USER_AGENTで判断している。
"MSIE 7"のときだけ元のページに飛ばす。

6以前はさすがに対応しなくてもいいか・・。

2008年10月26日日曜日

迷った末

迷った末に、IE8でも効果が大きいことから、fromEncodedバージョンをbothにしたときも採用した。

こちらはまだまだ修正の余地があるが、動作自体は問題なくIE7以外では効果があるはずなのでお試しいただきたい。
動作方法は、いつも通りInput&Output ver.実行するだけだ。

ちなみにChromeを使ってる人はあまり実感がないかもしれない。

2008年10月25日土曜日

逆転現象

Shortest Path GraphicのPriorityをbothにしたとき、IE7ではEncodedしたほうが表示までが遅くなるという話はしたが、IE8betaでは圧倒的にEncodedした方が速くなっている。

IE8のbetaがとれれば正式稼働すればこの方が良いと思うのだが、それまでは現行バージョンにしておいたほうが良いのだろう。

どちらにせよGoogleChromeやFirefoxなどといった高速なブラウザに比べれば差は歴然でユーザーにはそういったブラウザを推奨したい。

2008年10月24日金曜日

Encodedバージョン

GoogleMapsの表示にfromEncoded機能を用いたものもすでに公開されているようだ。

ただ、どうやらpriorityにbothを選択したときは今までと変わらずEncodedされていないものが採用されたままだ。

IE7では通常表示のみで20秒程度で距離優先、速度優先両方とも表示される。
しかし、Encoded機能を用いた場合それが30から35秒かかってしまい、大きなタイムロスとなる。
表示されてからが速いと言ってもさすがにこれだけ差があると導入に踏み切れないのだろう。

ちなみに、Shortest Path GraphicではIEは推奨していない。

2008年10月23日木曜日

IE8での挙動

IE8をインストールして新バージョンと比較してみた。
今時ブラウザのインストールで再起動を要求されたり、β版にもかかわらずIE7をしっかりと上書きしたりするのは見なかったことにしておく。


旧バージョン(Encodedなし):
「スクリプト実行に時間が・・・」のダイアログ表示が出る。

新バージョン(あり):
ダイアログが出ない。

IE7とIE8では圧倒的にIE8が速い。体感ではOperaより速いイメージがある。
とはいえ、IE8で実行した後にChromeで実行するとやはり圧倒的差がある・・。

2008年10月22日水曜日

各ブラウザの挙動

新機能を入れるときは大手ブラウザでは実験している。

Encodedしたときの各ブラウザを比較してみた。

GoogleChrome
GoogleMapsというGoogleのシステムなだけあって、すべてにおいて問題なく、かつ他ブラウザに比べて圧倒的な体感速度。推奨ブラウザの一つ。

Firefox3.0.3
Chromeほどではないが十分高速かつ安定した表示をする。推奨ブラウザの一つ。

Safari
Firefoxより若干遅いイメージがあるが、差はほとんど感じられない。個人的にFirefoxの方が好きだから主観が入ってるのかもしれない。推奨ブラウザの一つ。

Opera
上記3つに比べると体感1ランク遅い。Encodedされたラインがなんだか表示されないことが・・。
移動して中心に持って行くと表示される。挙動がなんだかおかしい。

IE
Windowsユーザーなら1度は使ったことのあるブラウザ。
Operaに比べて体感2ランク遅い。表示自体は安定。1回表示されてしまえばEncodedバージョンでは他ブラウザとも大きな差は感じられない。


Encoded機能では表示までの時間は変わらないものの、表示されてからの操作が格段に速くなっているのが注目すべきところだろう。どのブラウザでもそれを体感することができる。
Operaの怪しい挙動はどう対処していこうか・・。

2008年10月21日火曜日

表示速度の比較

実際に描画にどのくらい差があるのかを時間計測してみた。
結果表示ページでF5を押すことによって計算時間を省けるため、実表示時間のみを計測できる。


通常の方は結果ファイルのリード、表示のまでの時間。
Encodedの方は結果ファイルのリード、エンコード、表示の時間になる。
IE以外のブラウザでは速すぎて差が分からないため、IEでのみの計測結果を表示する。

通常:11秒
Encoded:12秒

符号化のロスもあり、わずかにEncodedの方が遅い。
しかし、通常の方では「スクリプトの処理に時間がうんぬん」のダイアログが出てしまうが、Encodedの方では出ない。また、表示されてから拡大縮小の処理がスムーズにでき、全体としては明らかに上回っているだろう。

Encodedの方は、少しアルゴリズムを改善するなりで11秒の方に近づける可能性も残っている。

2008年10月20日月曜日

Encodeによる階層化

GoogleMapsのEncoded機能により距離による階層化を導入してみた。

体感できるくらい速くなりました。
読み込みこそそれなりに時間がかかるものの拡大縮小の処理の時にIEでもスムーズ。

まだ実装できる段階ではないので修正して早めに正式導入したい。

やはり、線の描画処理でだいぶ時間がかかるということだろう。

2008年10月19日日曜日

Encode化

実際にEncode化して表示までの速度を計ってみると、Chromeではあまり変わらないがIEではEncodeした方が遅くなっている。

また、実際にEncodeにかかる時間を調べてみると推測値1秒程度で終わっており、表示の時の差(約5秒)ほどではない。
やはりこれは、レベルに応じて表示するかしないかの処理を入れてから計ってみた方が良さそうだ。

2008年10月18日土曜日

サーバー側での符号化作業

実際に行っているわけではないがサーバー側で符号化するとしても問題点が生じる。

現時点では距離を出していないが各点間の距離を求める必要があることだ。

ただし、当たり前だが、ダイクストラ法の時点で各パスの距離はあるのでそれから求めてもよい。
また、次の点との距離を求めるのにはただ単に座標を用いて計算するのでもよい。

そもそもJavascriptでやってもたいして時間が変わらないという話もあるので、IEのみの対策になりそうだ。

今のところIEはサポートはしているが、推奨はしていない。

2008年10月17日金曜日

fromEncodedの効果

GPolyline.fromEncodedを実際に使い実装してみた。

特に拡大縮小等のときの処理を用いていないので、まだまだ改善の余地はある。


現時点では、速度的にはほとんど変わった印象はない。
ただし、変わってないと言っても符号化の時間を含めても変わっていないということなので、
符号化をサーバマシンで行ったり、拡大縮小を取り入れたりすれば話は変わってくるだろう。

2008年10月16日木曜日

ちょっと休憩

少し休憩して、一番重要な初期バージョンでの画像ファイルの大きさの検証をしてみる。

検証にはNYのグラフファイルを用いている。

入力画面のarcファイル
BB Ver. 612KB
NB Ver. 226KB

出力画面のファイル
BB Ver. 1.43MB
NB Ver. 10KB + 226KB(Path_file + arc_file)
(合成画像出力時 503KB)

となっている。
NBバージョンでは、入力画面で226KBの容量の画像を読み込むが、出力時は10KBのパスファイルと、入力画面時の画像226KBを重ねて表示する。
単純に足して236KBと考える人もいるだろうが、ブラウザがキャッシュから読み込んでくれる可能性は高いので実質10KBしか読み込まなくてよい。

BBバージョンでは1.43MBくらい別に良いかと思ってそのまま合成した画像を出力している。

2008年10月14日火曜日

高速描画

GoogleMapsではPolylineを用いてラインを引いている。
しかし、直接かつ大量の描画は動作が遅くなるというのはどうやらGoogle側も認識しているようだ。

そこで、Encoded Polyline Algorithmによって符号化することで高速化することができるようだ。
実際に1万点を超えるラインの描画はその符号化の計算時間も含めなければならないが、1度作ってしまえば読み込むだけなのでどちらがよいかは実際に作ってみるしかない。

KMLファイルの戦略を断念したのでこちらを試してみることにする。

符号化についてはこの当たりのページが参考になりそうだ。
http://hwat.sakura.ne.jp/hpod/200609/14-200000/

Google公式のアルゴリズムについてはこっち
http://code.google.com/intl/ja/apis/maps/documentation/polylinealgorithm.html

2008年10月13日月曜日

評判

Web上でサービスを公開していると色々と意見をいただいたりするが、今のところShortest Path Graphicには悪い意見はほとんどない。

KMLファイルに関しては公開したばかりで何も情報がないが、こちらもGoogle上のサーバーにも負担をかけることがないし、オフラインでも実行できるという利点もあり悪い評判は出ないだろう。
有名な都市間の最短距離、最速距離を求めておいてGoogle Earth上でその都市間のルートを検索すると面白い。

2008年10月12日日曜日

Google

Googleの検索で、

Optimization Online

と検索すると3番目くらいに表示されるようになっている。(日本語環境下でWeb全体から検索)

Shortest Path Graphic

で計算するとこのブログが一番上に、本来のページが2番目に表示される。


Shortest Path Online や Shortest Path

の検索でもトップページに来ればいいのだが。
いずれにしても名前は正式決定ではないが。

2008年10月11日土曜日

KML版公開

結局のところ、Google側のサーバーの仕様上どうしようもないと判断した。
そのため、最短路を計算、KMLファイルを作成しそのままダウンロードしてGoogle Earthを用いて使用できるバージョンがすでに公開されている。

今回の仕様は以下の通り

1,いつもの入力画面
2,いつもの計算ページ
3,KMLを作成するページ
4,ダウンロードするページ

ブラウザにもよるが、基本的に2~4は見えない。(4は空白のページが見えることもある)

3と4で分けているのは、KMLを使用して表示するバージョンの名残りなので特に意味はない。
Google側のサーバーの仕様変更によってすぐに対応できるという意味も含めてはいるが。

2008年10月10日金曜日

エラーの原因

表示されないエラーの原因を調べてみた。

GoogleMapsでは、直接URLを指定することでkmlファイルを表示することができる。

http://maps.google.co.jp/maps?q=http://hogehoge.jp/test.kml

にすれば読み込むことができる。

そこで、表示されるファイルと表示されないファイルをやってみると



・表示されるファイル→表示される(当たり前か)

・表示されないファイル→サーバーエラー。
場合によっては、ファイルが存在しないというエラーもある。

となる。

2008年10月9日木曜日

仮バージョン

いったんはKMLファイルを利用したInput&Outputバージョンを公開したが、色々事情があって旧バージョンに戻した。

実際に同じ入力でも結果が表示されたりされなかったりで安定しないことが原因。
短い距離の場合はいつでも表示されるため、KMLファイルの大きさによってGoogle側が拒否しているのかもしれない。

このままでは無駄になってしまうが、KMLファイルのダウンロードをできるようにすればGoogleEarthでも読み込むことができるし応用がないわけではない。

2008年10月8日水曜日

kmlによる描画

kmlに変更する基本的な作業は終わっているが、今のまま移項してしまうとChromeやFirefoxなどの高速なブラウザで実行してしまうとただの劣化版に見えてしまうため、完全に同機能を備えてからの公開になりそうだ。来週くらいまでにはなんとかしたい。
とはいえそのブラウザでも少しは速くなっているしIEでは体感300倍くらいの高速化がされている。

2008年10月7日火曜日

CEATEC

CEATEC JAPANに行ってきたが、GoogleEarthなどを利用している企業も多い。
簡単に実装できる仕様で、かつ高機能で見栄えがいいというのが魅力なのだろう。

軍事目的の使用などは危ないが、機能としては魅力的だし、誰が見ても面白いと思えるでしょう。

2008年10月6日月曜日

kmlファイル対応策

kmlファイルのキャッシュの問題だが色々調べているとどうやらアドレスで判断しているらしいことが分かった。
kmlファイルの後にゴミをつけてやればキャッシュを読みに行かずすぐに反映される。サーバに対してはあまりよくないのかもしれないが・・・。

今更感があるが、自前のサーバにGooglemapsを設置し、kmlファイルを読み込む方法は

map.addOverlay(new GGeoXml("http://honyanyara.jp/t.kml?gomi=hoge");

2008年10月5日日曜日

kmlファイルの読み込み

どうやら、kmlファイルの更新が反映されるにはある程度時間がかかるようだ。
GoogleMapsのサーバにキャッシュか何かが残っているのだと思われる。

Firefoxで実行した結果がIEでは実行していないはずの結果として表示されたりするので、ブラウザのキャッシュではないと言うことが一応の根拠。

GoogleEarthでは結果がすぐに反映されているので、その辺の仕様は違うのでしょう。

2008年10月4日土曜日

問題点

先日から話しているが、今回作成しているバージョンでは、kmlファイルを読み込んでいる。

kmlファイルがアクセスしたりダウンロードしたりすれば、自分のGoogle Earthでも読み込むことができる。


本題の問題点。
1回目の実行は問題なく実行でき、今までに比べ高速(特にIEで体感)でできている気がする。
が、2回目の実行が反映されない。
そこで、Google Earthから読み込んでみるとしっかりと反映される。

キャッシュの問題なのかGoogle側の問題なのかわからないがキャッシュの問題ならページをキャッシュさせないなどの処理が必要になる。
Google側がそのような仕様にしているならあきらめるしかない。

2008年10月3日金曜日

kmlを用いたShortest Path Graphic

試作品の試作品の試作品くらいのものを作ってみた。

現時点での仕様は確定ではないがこんな感じになる予定

1,いつもの入力画面
2,いつもの計算ページ
3,kml形式のファイル書き込み
4,kmlファイルを読み込んで表示するページ

1,2は基本的に何も変わらないが、3,4を新しくしている。
とはいってもユーザーから見た目はほとんど何も変わらない。

2008年10月2日木曜日

kml

Google Earthにはkmlと呼ばれるファイル形式があり、ポリゴンデータやプレイスマークなどがxml形式でかかれている。

これはGoogleMapsでも(一部形式のみ)使うことができるため、これを使うと表示を速くすることができそうという見通しがある。
実際にやってみてもIEでもストレスなくとまではいかないがちょびっとストレスくらいで表示することができる。

しばらくはこの作業を色々実験してみようと思う。

2008年10月1日水曜日

Shortest Path Graphic

しばらくブログを更新しませんでしたが生きてます。入院もしてません。
なんだか内定式とかもあったりで忙しかったことにしておいてください。


その間にもShortest Path Graphicの入出力バージョンも無事公開されたようで、だいぶ好評だ。

ただIEでの表示が遅いため、色々改善策が出てきている。

2008年9月15日月曜日

GoogleMapsのクロスブラウザ問題

今回もShortest Path Graphicに新機能などを入れるためにいくつかクロスブラウザ問題が発生している。

一番重要なPolylineの表示だが、IEではデフォルトでは表示することが出来ない。

<html xmlns="http://www.w3.org/1999/xhtml">

などをincludeする必要がある。

Operaでは

echo("map.addOverlay(new GPolyline(points,'red',"5","0.7"));");

と言うように使えず、色の指定はRGB値を指定しなければならない。これだと青のラインが表示されてしまった。

大きな問題は上の2つくらいだろうか。
FirefoxでもJavascriptからHTML内のオブジェクトとつなげにくかったりといった直接は関係ないものもあったが、厳密に記述すれば解決できるのでそれを心がけていけばよい。

これだけブラウザが増えてしまうと実験だけでも一苦労だ。
特にIEはJavascriptが遅すぎてCPUファンはうなり出すわ結果は出ないわでストレスがたまります。
スタイルシートは一番IEが気持ちを読み取ってくれる気がしますけど。

個人的にはFirefoxメイン、Google系のアプリならGoogleChromeが良いかと思ってます。Chromeはセキュリティホールも結構見つかってるようですし。

2008年9月14日日曜日

GoogleMapsを使ってみる15

入出力をGoogleMapsにしたShortest Path Graphicも来週くらいには公開になりそうだ。

新バージョンの新機能等は以下の通り。

1,入力画面もGoogleMaps
2,入出力ともにマウスホイールでのZoomIn、ZoomOutに対応
3,出力画面の最初は入力画面の縮尺、中心座標で表示

2の機能マウスホイールに関しては、他のバージョンの出力にはすでに先行導入されている。前々から入れたかったのだが、APIをただ見逃していただけでした。

map.enableScrollWheelZoom();

と入れるだけで実装できる。

3は今までは2点間の中心座標とZoom値11というようにしていた(特に何の根拠もない)。今回は入力もGoogleMapsということでそのような仕様にした。
今までのバージョンも中心だと道を外れる可能性もあり、始点を中心に表示するよう変更されるかもしれない。

2008年9月13日土曜日

GoogleMapsを使ってみる14

Shortest Path Graphicの入出力ともにGoogleMapsを用いたバージョンも作成が進んでいるようだ。

昨日の問題点1
クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)

については地道な作業をすることでなんとか実装している。
GoogleMapsの機能として住所が分かればそこから緯度経度を出すことは可能なのだが、逆が出来ないようでちょっと面倒な作業になってしまった。

inUSAという関数を作り、戻り値が1ならUSA内(正確にはハワイとアラスカは除く)で0ならアウト。といったかんじ。
大まかには長方形で囲んで中にあるか外にあるかを判定。
それだけではカナダとの国境などが危ないので、もう少し判定を厳しくする。

カナダとの国境は幸い、大まかには緯度が同じ地図上で言う真横にひかれたラインと斜めにひかれた直線でいる。そのため、斜めの直線とクリックした点の右上右下判定だけすればある程度細の判断までできる。
厳密にはまだまだだが、実装レベルとしては悪くないのではないかと思う。
自分一人では何とも言えないので色々意見をもらうことになるだろう。

2008年9月12日金曜日

GoogleMapsを使ってみる13

GoogleMapsバージョンも公開されたShortest Path Graphicだが、どうやら次は入力部分もGoogleMapsに対応する予定のようだ。


入力にもGoogleMapsを使う意味や利点は以下の通り。
1,結果もGoogleMapsなのだから当たり前。
2,マーカーのドラッグ機能などを駆使できる。
3,拡大縮小が自由にできるため細かい値を指定しやすい。


問題点は以下の通り。

1,クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)
2,すべての計算が全米になってしまうので負荷がかかる。


1はユーザーが正しいものを入力してくれると信じれば特に気にする必要はないため、実装は後にする方針。緯度経度の取得はできるので最低限なんとかなるだろうということもあり楽観視しているという噂もある。

2はとりあえず見ないことにする。P2Pバージョンに限定するなどの処置を取ることも場合によっては視野に入れる必要があるかもしれない。


利点の2について少し説明する。
基本的に今まで用いてきた技術を変えていけば作成可能になるが、ドラッグイベントの処理は少々面倒なので今まで使っていたのとは違い以下のようにしてみる。

var newMarker = new GMarker(point, {draggable: true});

でドラッグできるマーカーが作成できる。

var map;
var marker_num=0;
var marker1=null;
var marker2=null;
var tmp_marker=null;
var marker1_tmp = null;

function eventMarker(point){
map.closeInfoWindow();
var newMarker = new GMarker(point, {draggable: true});
if(marker_num % 2 == 1){
tmp_marker = marker2;
marker2 = newMarker;
}
else{
tmp_marker = marker1;
marker1 = newMarker;
}
GEvent.addListener(newMarker, "dragstart", function() {
map.closeInfoWindowHtml();
});

GEvent.addListener(newMarker, "dragend", function() {
var currentPoint = newMarker.getPoint();
newMarker.openInfoWindowHtml("latitude: " + (currentPoint.lat()) + "
longitude: " + (currentPoint.lng()));
});

GEvent.addListener(newMarker, "click", function() {
var currentPoint = newMarker.getPoint();
newMarker.openInfoWindowHtml("latitude: " + (currentPoint.lat()) + "
longitude: " + (currentPoint.lng()));
});
map.addOverlay(newMarker);
if(tmp_marker!=null)map.removeOverlay(tmp_marker);
marker_num++;
}

また、load()関数の中で

GEvent.addListener(map, "click", function(overlay, point){
if(point){
eventMarker(point);
}
});

しておけばよい。marker1とmarker2を使い、3つめのマーカーが作られたときに古い方のマーカーを消す作業を入れている。これは既存のShortest Path Graphicと同じような仕様だ。

参考:http://www.tatamilab.jp/~ooi1/GoogleSample5.html

2008年9月11日木曜日

GoogleMapsバージョン

例のページ(http://opt.indsys.chuo-u.ac.jp/portal/)でGoogleMapsを使用したバージョンもどうやら公開されたようだ。

公開はされたが、拡大を大きくすると若干のずれが生じてしまうのは今も変わらないのでメルカトル図法用の座標計算をし直すのを導入するしかない。

また、ほぼ同時に全バージョンで時間優先、距離優先の選択肢が追加されたようだ。
GoogleMapsのP2Pバージョンではその両方の結果を表示するオプションもついている。

2008年9月10日水曜日

Google Mapsの道検索

GoogleMapsの道検索では厳密な最短路は求めていない。
もちろん車で移動することを前提にしているならば、時間優先の探索になるであろうしその方が現実的だ。
データは違うものの時間優先検索で検索した結果と「ほぼ」同じになっている。
違う点は、GoogleMapsの方が分岐の近くでも大きな道路を選んでいる。

スタートとゴールの近くの大通りまで出てあとは大通りを進めばよいと言う発想だろう。
これを見ても時間優先の厳密解ではないと思われる。
そもそも、信号等の不確定な状況下なので厳密解まで必要ないということなのだろう。

2008年9月9日火曜日

理想

二つのマーカーを用意して、それらをドラッグ&ドロップで動かしてその先までの最短路を(ほぼ)瞬時に表示するなんていうことができるならばそれはユーザー側にとってはありがたいし、カーナビへの応用も利くだろう。
実際はどこでプログラムを動かすか、ラインの表示はどうするか。再検索のときには今までのラインはどうするか。などといった問題が生じる。
あくまで理想の段階で、現時点で実装できる予定はない。
Browser側の進歩、各々のPCの進歩などでJavascriptですべて高速に計算できるのであれば実装はできそうだが現実的には難しい。

2008年9月8日月曜日

今後の方針

GoogleMapsバージョンも最低限は完成しているのでそろそろ公開になると思われる。

現時点で入力ページが今までと同じ画像表示になっていて、その名残から座標を使っている。結果表示のページではGoogleMapsのマーカーで座標表示ではなく緯度経度表示になっているため、なんだか変な感じがする。これらは入力側を修正することで対応したいと思う。

入力ページもGoogleMapsに関しては、良い方法があればすぐにでも採用したいんだが、なかなか思いつかないのが現状だ。

2008年9月7日日曜日

GoogleMapsを使ってみる12

GoogleMapsでは渋滞情報という機能がアメリカの方にはある。
各道路の渋滞情報を見ることが出来る機能で、おそらくGoogleがカーナビと連携して使うことになるのだと思われる。
map.addOverlay(trafficInfo);
で付け加えることが出来る。

直接最短路とは関係がないが、時間優先で最短路を求めてみると渋滞に巻き込まれやすいことがわかる。時間優先の最短路は、渋滞を考慮しているわけではなく最高速度で決まっているため、多くの人が最高速度が速い道を使っていると言うことだろう。
実際の速度とは大きく違うことになりそうだが。

2008年9月5日金曜日

Google Chrome

GoogleからGoogle Chromeというブラウザが出たので早速インストールしてみた。

別にGoogleのブログを使ってるから宣伝するというわけではないが、速さ重視と言うことで「最速」とも言われているFirefox3と比べて気になったというのもある。

Google ChromeはAppleのHTML描画が高速な「Webkit」を用いている。またJavaScriptを独自のV8エンジン(名前はV型8気筒エンジンに由来するらしい)を搭載して高速化を実現している。

残ったログを見てみるとユーザーエージェント(UA)は

AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

となっている。

Shortest Path Graphicの各バージョンで試してみたが問題なく動作することを確認している。

また、実際に動作させてみるとUSAのグラフで体感2倍くらいFirefoxより表示が速い。これは結構大きい。
GoogleMapsの拡大縮小などの処理はFirefoxより体感3倍くらい違っている。

どちらも正確に計ったわけではないが、体感速度というのはこういうサービスでは重要なことであろう。

機能面ではFirefoxの方が上であり、どちらを取るかはユーザー次第と言ったところか。

2008年9月4日木曜日

GoogleMapsを使ってみる11

今までの通常のShortest Path Graphicにもあった経由点を指定できるバージョン。
こちらもGoogleMapsに対応させるべく作業を進めている。

当初は、小一時間程度で終わると楽観視していたが、諸処に問題が発生することが次第に分かってきてだいぶ手間取っている。
座標の入力からクエリファイルの書き出しまではそのまま使用しているので問題はない。
プログラムに渡して出力が帰ってきてからが少々面倒になる。

前回の話にも出たマーカーはsetCenterの後でなければならないという仕様は意外に厄介な仕様になっている。
そもそも、Centerの位置をどこにしようかというのは難しいのだが・・。

2008年9月3日水曜日

GoogleMapsを使ってみる10

マーカーを使って緯度経度を表示するという話を前回したが、実際色々やってみると表示されないことがあり原因を調べてみた。

var source_info = 'hoge';
var dist_info = 'hogehoge';
var marker1 = new makeMarker(point_source, source_info);
var marker2 = new makeMarker(point_dist, dist_info);

これはどこにいれてもいいというわけではなく、

map.setCenter(new GLatLng(41.2,-73.55), 11);

のようにsetCenterメソッドを先にいれる必要があるらしい。
そうしないとJavaScript側でエラーを返されてしまう。
なぜそのような仕様かはGoogleに聞かないと分からないですが。
これに気づくのに時間がかかりすぎてしまい、後々手間取ることになってしまいました。

2008年9月2日火曜日

GoogleMapsを使ってみる9

GoogleMapsのOpenInfoWindowを使用して始点と終点に緯度経度を付け加えてみた。


function makeMarker(point , info_text){
var marker = new GMarker(point);
GEvent.addListener(marker, "click" ,function(){
marker.openInfoWindow(info_text);
});
return marker;
}

このように、関数を使って、イベントを作成しておくと後が楽。

var source_info = 'hoge';
var dist_info = 'hogehoge';
var marker1 = new makeMarker(point_source, source_info);
var marker2 = new makeMarker(point_dist, dist_info);


とすれば実際にマーカーが表示される。
この場合、point_sourceなどは、GLatLngでセットしておく必要がある。
HTMLタグを使いたいときは上の方のOpenInfoWindowをOpenInfoWindoHtmlにすればよい。

参考:http://japonyol.net/editor/googlemaps.html

2008年9月1日月曜日

GoogleMapsを使ってみる8

GoogleMapsバージョンで新しく加えようと思っている機能(すでに実装されているものもあり)は以下の通りだ。

・距離としての最短路を求めるか時間(速度制限等を考慮)を最短にする道かを選択。
両方同時も考えているが、問題が生じる可能性もあり詳細は考え中。

・各マーカーに緯度軽度の情報を加える。
GoogleMapsのOpenInfoWindowを使用。

・入力された始点と終点が両方表示される縮尺に自動変更。
緯度経度の値から計算するしかない。
現在は適当な縮尺で固定して、中心は2点間の中心にしている。

2008年8月31日日曜日

GoogleMapsを使ってみる7

前回、実際に実装したという話をした。

場所によっては地球が丸いからか地図データが違うからかはさておき、やはりずれているのが気になる部分がある。
とはいえ橋などの一番重要な部分に問題がないのが幸いだろう。
国道?のような大きな通りでもずれが出ている部分があるが、道路の形と線の形が似ているため、目分量で修正することもできる。

2008年8月30日土曜日

GoogleMapsを使ってみる6

今までの話を総合して下のような形でGoogleMapsを使った最短路オンラインソルバーを実際に作ってみた。

・入力ページは今までと同じ(2点をクリックしてSubmit)
・計算時に画像の作成、結合処理が不要なので削除。
・上記の代わりに到達点までのルートを出力。
・出力ページはシンプルにGoogleMapsが出力されるのみ。

実際に動作させてみるとおおむね問題なく動作。
心配されていた処理の遅さも気になることはない。(ナローバンド環境下ではわからないが)
地図データの違いからか地球が丸いからかはわからないが、道のずれも多少はあるもののそこまで致命的ではない。

2008年8月29日金曜日

GoogleMapsを使ってみる5

引き続き問題点を。

今回こちらで用いているデータは交差点から交差点への座標(緯度経度)である。
すなわち地図データがないためカーブはすべて直線で表されることになる。

大きな問題のようにも見えるが、実際はそこまでは1本道のはずなのでそれほどではないはず。(ただし、見た目が悪くなる可能性はある)


入力にGoogleMapsを用いた場合USAデータ以外に対応していない現在はそこをどうするかを考えなくてはならない。
マーカーのセット時にUSA内かを判断するなりしなければならない。
とりあえずは入力は今までのページでいいだろう。

2008年8月28日木曜日

GoogleMapsを使ってみる4

実際に実装するときの問題点を確認。

・実行時間はどうか?
・グラフデータに違いがある。
・その他

実行時間についてはやってみないと分からないとしかいえません。
ただ、GoogleMaps自体がそんなに軽くないし動かしたりするとCPUががんばっちゃったりします。ラインを引くのは数本はやってみたけど大丈夫な予感。

グラフデータに違いがあるというのは今回の最大の問題点。
GoogleMapsで使用されているデータと使用しているTigerのデータでは少し違いがあること。
これが細かいところに影響してくるでしょう・・。

その他
微妙に規約に引っかかりそうだったけどセーフな部分。
リアルタイムルート案内を禁止しているみたいです。車両と通信するシステムについてだからとりあえず問題ないはずだけど。

2008年8月27日水曜日

GoogleMapsを使ってみる3

前回までの話を使うとそのまま、最短路問題に移行できる。
事前情報ではラインを引くのが遅いというものもあったがいかに・・。

事前操作としては、
1、座標の修正。
2、ページの作成。

座標の修正は、座標をGoogleMaps用に緯度経度に変換する作業。
元のグラフデータが緯度経度を元にして作られているのでそれほど大きな問題はない。

ページの作成。

出力ページは完全にGoogleMaps依存のページに変更。
比べるという意味で、今までの画面はあってもいいかともおもう。

入力ページは
1,今までと変わらず。
2,こっちもGoogleMaps使っちゃおう。

その2択かなぁと。

2008年8月26日火曜日

GoogleMapsを使ってみる2

マーカーの設置方法。
var point = new GLatLng(33.613158, -117.640931);
var mk = new GMarker(point);
map.addOverlay(mk);

これだけでただのマーカーが出現する。

ラインの引き方。
point0 = new GLatLng(34.983939, -78.773673);
points.push(point0);
point1 = new GLatLng(34.984196, -78.775077);
points.push(point1);
point2 = new GLatLng(34.984277, -78.775519);
points.push(point2);
point3 = new GLatLng(34.984444, -78.775971);
points.push(point3);
map.addOverlay(new GPolyline(points,'red',1,1.0));
で、0->1->2->3のラインが引かれる。

ここまで来るとShortest Path Onlineも楽に実装出来るのではないかと思い始める。

2008年8月25日月曜日

GoogleMapsを使ってみる

実際にGoogleMapsがどんなものかと使ってみる。
APIキーを申し込んだらサンプルが表示されるのでそれをそのままコピペしたページは一応動作する。それを基準にちょこちょこ変えていくのが楽そうだ。

現時点でのバージョンは2がデフォルト。1を使って説明しているページもあるのでそこは注意。特に座標の設定が違う。

point = new GLatLng(34.983939, -78.773673);

のような感じ。

縮尺とか航空写真のボタン?はデフォルトでは出ないらしくオプション扱い。

map.addControl( new GSmallMapControl() );
map.addControl( new GMapTypeControl() );

SmallではなくLargeにすると縮尺?みたいなやつもでてくる。

右下に窓を表示して今の場所とかをみたいなら

map.addControl(new GOverviewMapControl());

で追加できる。

2008年8月23日土曜日

Google Maps

GoogleMapsを利用して最短路を表示しようというのは前々から議論されている。
前持った情報では時間がかかるなど言われているが、最短路であればそれほど本数が増えないのではないかと考えている。
実際にやってみなければわからないが、GoogleMapsで最短距離が示されれば説得力もあがるしなんとか導入してみたいところだ。

2008年8月22日金曜日

ソースファイル

現時点では中の計算をしているソースファイルの公開はしていないが、将来的には公開される予定だ。

バイナリを実行してもオンラインソルバーのように視覚的に表示されるわけではないので、バイナリ公開後もこちらの需要が減ることはないだろう。
また、今のようにグラフィカルに表示するだけでなくルートのみを示したものを出力するようなバージョンがあっても面白いかもしれない。

2008年8月21日木曜日

内部処理

昨日Shortest Path Graphic において、座標処理を緯度経度に変更していると書いた。
とはいえ、表示している値は座標なのでその値を軸に考えなければならない。
場所によっては緯度経度で入力したモノをもう一度座標に戻しているものもあり、一長一短である。

将来Google Mapsを使うとして必要なある点における緯度経度取得はできるような状況である。
非公開のクエリ作成ページでは座標とともに、実際の緯度経度を表示するようにしている。

2008年8月20日水曜日

緯度経度

現在のShortest Path Graphic の座標の計算を緯度経度を用いるように変更している。
将来的にGoogle Mapsなどと連携できるとおもしろいと考えているため、そちらの仕様にあわせる必要があるためだ。
ちなみに現時点では見た目も結果も何の変化もない。

2008年8月19日火曜日

すっかりと

すっかりとお盆休みから放置してしまったのでぼちぼち更新します・・。

2008年8月16日土曜日

最短路

先日の関西での出来事だがカーナビが10kmの距離を2時間と言い始めた。

普通に歩いてもそのくらいの速度で歩けるものだが、実際は高速を降りて下道にはいればもっと早く着いた。
今のカーナビがどんなシステムなのかはよくわからないが再探索や、いわゆる裏道も入っていると非常に便利であろう。
経験則では目的地が近ければバスについて行くのが早い気がする。いくらかかるかわかりませんが・・。

2008年8月15日金曜日

高速道路

この季節になると渋滞の情報をよく聞く。

先頭の車が速度を落とすとそれが後ろに影響していき渋滞を引き起こすわけだが、速度が落ちるのは本来料金所くらいなはずだ。
気づかないような上り坂で少し速度が落ちたり、速度違反取締機直前で速度違反の車が速度を落としたりが影響しているのであろう。
後者はさておき、前者は普段から運転慣れしていればある程度は回避できると思うのだが・・。

2008年8月14日木曜日

実家

一人暮らしを始めてしまうとなかなか家族がそろうこともない。
久々に母方の実家に家族そろって行った気がする。

大家族が減った現代ではこういった現象が増えているんでしょうね・・。

2008年8月13日水曜日

関西 その5

それにしても京都付近には歴史的建造物が多い。

ただ、関東もそうだが、暑いにかわりはない・・。

2008年8月12日火曜日

関西 その4

阪神大震災から結構な年数が過ぎたが、それにしても神戸の復興は早い。

しばらく大地震も来ないだろうし、神戸は数十年間住みやすいところなのではないだろうか。
神戸の人には失礼だが、意外に都会でした・・。

2008年8月11日月曜日

関西 その3

比叡山から見える琵琶湖は綺麗でした。

延暦寺に行くには山道を行かなければならないので車で来ないとなかなか行きにくいところだった。
山道が続くため酔いやすい人は注意した方がいいだろう。

それにしてもよくもあんな山の上に色々立てたものだ・・。

2008年8月10日日曜日

関西 その2

関西大学の建築系の研究室におじゃまさせていただいた。
建築系の分野とは全然関わったことがないのでなんだかスケールが大きい感じがしました。

他分野を見るというのも重要なことだと思います。
関西人はほんとに人当たりのいい人がおおいですね。

2008年8月9日土曜日

関西

6日から関西の方に来ている。

来る途中覆面がいたり雷雨があったりとなかなかスリルのある移動であった。
最初から最後まで運転した先生には感謝感謝です。。

京都は焼きそば一つとってもおいしいです。

2008年8月8日金曜日

scanf

先日scanfの返り値で取得した変数の個数をカウントできる話を書いた。

取得した変数の個数をちょうどにしたい場合は、多めに1つ%sを取得しておいて返り値で調整すれば良い。

2008年8月7日木曜日

PHP

header(location:"url");
というのをページ遷移によく使っている。
ural?hoge1=xxx&hoge2=yyy
というようにすれば変数もGETで渡せるので非常に便利。

それを利用していたら
Header may not contain more than a single header, new line detected.

というのが出てきたんだけど、なんでしょうこれ。
変数の中に改行文字とか入ってるとまずいのかな??

最悪一旦ファイルに書き込み、それを読み込んでファイルを消すという方法もあるのでそこまで重要視してはいないがなんだかいろいろとしっくりこない。

2008年8月6日水曜日

C言語

最近全然C言語を作っていなかったのでチェックプログラムを作成したときのC言語はだいぶ久々であった。
それなりには組めるがやはり基本的事項を忘れていたりするのはまずい。こういうのはやはり反復が大事なのだろう。

不覚にも、scanfの返り値が取ってきた変数の個数というのは知らなかった。
セグメンテーション違反とかにはならないので色々使い道がある。得にチェックプログラムでは1文字ずつ読まなくてもすむため、非常にありがたい。

2008年8月5日火曜日

クエリのチェック

クエリのチェックプログラムは一応完成して、よほどの場合でない限りは正しいものかどうか判断できる(と思う)
非公開で動かしているものでも今のところ問題はないようだ。

チェック時にエラーが起きたときはエラーしか表示しないようにしているため、どのラインにエラーがあったのかくらいは書くべきであろう。

すでに公開できなくはない状態だが、需要があるのだろうか・・?

2008年8月4日月曜日

PHPからのプログラムの実行

PHPからプログラムやコマンドを実行するのにsystem、execなどが用意されている。また、shellの実行もshell_execなど別に用意されている。

Cでコンパイルしたバイナリで表示された値を取得したかったので何かいい方法がないか探したのだが直接はどうも読み出せなかった。

仕方がないので
binary.shにCでコンパイルしたファイルの実行を入れ、

ataigahosii = exec("sh ./binary.sh");

とやったら値を取得できた。本当はほかにいい方法があるのだろうけどとりあえずこれで行くことにする・・・。

2008年8月3日日曜日

クエリ仕様の公開に向けての作業

先日お伝えしたとおり、Shortest Path Graphic でクエリを直接入力できるようなバージョンを作成している。
全員が正しいクエリを入れてくれれば公開してもいいのだが、色々実験する人も出てくるであろうし世の中には悪い人もいるのでクエリのチェックをかけなくてはならない。

どんなファイルを入れてくるかわからないので色々テストもしなければならないので結構大変な作業になるかもしれない。

2008年8月2日土曜日

クエリ仕様

Shortest Path Graphic に新たに、クエリを直接入力できるバージョンを作成している。

Dimacsのデータの一部を使用できるような設定になっているが、知らない人の方が多いであろう。
そこで、クエリ作成のページも作成し、設定した道順のクエリを出力できるようにした。

これは、実際にバイナリを配布することになった後でも使えるようにすることも目的にある。

2008年8月1日金曜日

表示されないバグ

最近は少なかったが、Shortest Path Graphic で結果が表示されないことがあるバグが見つかっていたが、原因不明だった。

今回、超高解像度版だと頻繁に起こっていたので調べてみると表示できないのはブラウザやOSの問題ではないかという推測になっている。
Windowsだとほとんどのブラウザで表示できないがLinuxだと32ビット、64ビット関わらず、またFirefox2,3両方とも表示されている。

Shortest Path GraphicではLinux+Firefox(できればver.3)を推奨しているようだ。

2008年7月31日木曜日

オープンキャンパス2

オープンキャンパスの時に学食のメニューが少なかった。
こういうときこそメニューをしっかりとそろえたり人件費を使ってもいいと思うのだが。

前にいた大学では学食の無料券を配っていた気がする。
もちろん無料券を配るだけでは意味がないし質も上げていかなければならないと思う。

2008年7月30日水曜日

オープンキャンパス

先日オープンキャンパスがあって、今回のうちの研究室のメインはShortest Path Graphicであった。

そもそもコンピュータに興味のある学生はうちの学科にはこないのか、詳しい人はほとんどいなかった。
まだ高校生だし、学科の中身までわかる人は少ないのだろう。
学生には大学名や学科名だけじゃなく中まで考えて選んで欲しいと思う。
とはいえ日本の風潮が学歴社会だから微妙なのだが・・。

2008年7月29日火曜日

高解像度版2

昨日の続きになるが、高解像度版では画像のeps->pngの変換に時間がかかっている。
そのため、基本仕様はナローバンド版と同じでPNG画像の重ね合わせで実装している。
画像のダウンロードもできるようにはなっているが、上で描いたように画像の変換に時間がかかるため、ダウンロードボタンを押してもなかなか画像が表示されない。

こちらももう少しいい工夫があれば変更していきたいところだ。
今は、画像変換にはconvertコマンド(ImageMagicを使用)で実現している。

2008年7月28日月曜日

高解像度版

オープンキャンパスでのデモのために高解像度版ができている。
USAのグラフも真っ黒ということはなくある程度道がわかるようになってイカサマではないことがわかる。

どうせなら・・・と超高解像度版も作ってみたところだいぶはっきりしていた。
いろいろなところでデモするためにはこのくらいの解像度が欲しいところだ。

余裕があるなら公開したいとのことだが、いかんせん画像の容量が莫大すぎて公開には踏み切れない。

2008年7月27日日曜日

ネーミング

何の名前でもセンスが問われる。
子供に変な名前をつける親がいたりと問題になったりしているが名前をつけられた方の身になって考えてもらいたいものだ。

今はShortest Path Graphicとして公開しているが、正式な名前は決まっていない。
Graphical Shortest Path や、Shortest Path Online Solver など色々名前の候補はあるが、略称もうまくなるようにしたいなど色々と難しい。

2008年7月26日土曜日

座標の調整

Shortest Path Graphic を利用するブラウザによっては、左上端の座標が(0,0)にならないものもある。

IEやSafari、Firefox2では(0,0)になるのだが、Firefox3、Operaでは少し大きめになってしまう。
それによってクリックしたつもりの場所と結果が違うとおもっていたユーザーが多いかもしれない。

実際に調べて、ブラウザによって判別するようにした。Firefox3、Operaではx,y座標共に取得した値より8を引いた値を入力の値としている。

試してみると微妙なところをクリックしても思った点を指定できている気がする。

2008年7月25日金曜日

event.offset

座標を取得する際にJQueryを利用しているのは前にも書いた。

また、ブラウザにはCtrl + '+' or '-' などで拡大縮小することができるのだが普通のブラウザはそれによって座標が変わることはない。

IEはスクロールやそういった事象を考慮に入れている。
その割に画像のサイズ等の変更はしないため、取得する方法がわからなかったが、

x = event.offsetX;
y = event.offsetY;

で取得できることがわかった。ブラウザによって仕様が違いすぎて困る・・。
できればIEは使いたくないがシェアが大きすぎる以上仕方がない・・。

2008年7月24日木曜日

ナローバンド版

経由点を複数指定できるようになったShortest Path Graphic だが、どうやらナローバンド版も出たようだ。
前にも書いたが、日本だけなら必要のないバージョンだが世界的にはまだまだブロードバンドが普及していない国も多いため必要なものである。

通常の2点指定のバージョンと同じで、出力時はグラフファイルをキャッシュから読み込むことを期待して、透過処理を用いて実現している。
ブロードバンド版では合成した画像を表示しているため、その時点でキャッシュに入ることはないが、そもそもブロードバンドなので画像の重さはそれほど気にしなくても良い。
また、2点指定と同様に、それらを組み合わせた画像のダウンロードもできるようになっている。

公開がブロードバンド版よりも数日遅れたのはそちらの対応が思ったよりうまくいかなかったからのようである。

2008年7月23日水曜日

Line Width

Shortest Path Graphic では経路が表示される線の太さを2としてデフォルトにしている。
開発者やユーザーの間では細いし3か4にした方がいいのではないか?との意見も出ている。

ただ、Resolutionを1600にするとちょうどよく表示され、画像として保存した場合に2の方が綺麗になるという理由もある。
また、USAでは2でも太いくらいでマップに依存することかラも2が適切と判断している。

ログを見てみてもユーザーはデフォルトで実行することが多いので難しいところだ。
グラフやResolutionによって自動判断するというのも手かもしれない。

2008年7月22日火曜日

経由点バージョン

Shortest Path Graphicの経由点バージョンが数日前正式に公開されたようだ。

公開直後はバグがあったようだが、今はすでに修正されてるようで大きなバグは見つかっていない。
USAのグラフで中継点を多く指定するとやはり実行時間が増えてしまう。
それでも初期バージョンのように2点で1分かかっていた頃よりは高速化されているので10点以内なら1分かかることはないであろう。

どうやらこのバージョンでは同じグラフファイルで2人が同時に使用すると2人目は実行できなくなっているようだ。

2008年7月21日月曜日

Resolution変更

Resolutionを変更すると座標の方も変わるのが普通のShortest Path Graphicの仕様だ。
しかし、Viaバージョンでは複数の座標を渡しているため、その計算が非常に大変になっている。

ページを読み込んだときにすべての座標をJavaScriptの変数に格納してしまい、Resolutionが変更されたらすべての座標を計算する方法で実装した。

2点指定のバージョンでもそうだが、その時点の座標との相対値を使用しているため1回1回計算しているので最初の座標と少しずれてしまっていたりするのが難点・・。
元の座標から計算するようにそのうち変更する予定。

2008年7月20日日曜日

実行時間

いつの間にかShortest Path Graphicの結果画面で実行時間が表示されるようになっている。

実際の計算時間、画像の変更時間など内部処理に用いた時間をすべて計測しているようだ。
画像の読み込み時間などの測定はクライアント側のネットワーク等に大幅に依存してしまうため計測していない。
実際にはReal Timeに気持ちプラスした程度の時間がマシン側の時間であろう。

2008年7月19日土曜日

timeコマンド

Linuxのtimeコマンドは標準エラー出力されるため、ただのリダイレクションではファイルに保存されない。

(command obj > /dev/null) >& out

といったようにする必要がある。

2008年7月18日金曜日

中継点

中継点を複数指定できるShortest Path Graphicの準備はほとんど終わっている。
現在、バグ探しや、最終調整を行っているらしいので近いうちに公開されるだろう。

負整数の入力で無限ループに陥るなどのバグ報告があった。
入力をはじいてた部分を通らないように変更してしまったためであったがもう少し厳しくチェックをいれる必要がある。

また、結果表示ページに入力したルートを表示するかどうかは途中の仕様が変わっているので未だ不確定な状況だが、機能を落としたくないということでなるべく削らないで行く方向のようではある。

2008年7月17日木曜日

ソース改変による仕様変更

Shortest Path Graphic のクエリ変更に従い、今まで機能していた仕様を削除しているものもある。

Resolutionが変更されると座標も同時に変更する仕様になっていたが、1個以上座標が指定されているときは変更できなくなった。

元から同じサイズで扱えと言いたいところもあるので、大きな影響はないであろうがちょっと寂しい。

2008年7月16日水曜日

ソース改編3

引き続きShortest Path Graphicのソースの改編を行っている。

先日のClearボタンの話であるが、Setされた時点では入力されたデータは変数としては格納されていない。実際に扱うのは変更不可のテキストに入力されたデータから扱っている。

座標の指定が
(x1,y1) -> (x2,y2) -> (x3,y3)・・・
となっているため、->を基準にClearボタンなどを動作させている。

->が1つもなければ座標は1つ以下であるから全部クリアしてしまうことと同じ。
逆に2つ以上->があるときは一番最後の->まで消してしまえばよい。

->は複数存在するため後方検索しなければならないので、JavaScriptの
str.lastIndexOf()を用いている。

2008年7月15日火曜日

ソース改編2

Shortest Path Graphicのソースの改編を行っている。

今まで通りクリックで座標を指定するが、その時点では確定せずSetボタン(仮)を押すことで確定。
次の点を指定して同様にSetボタン(仮)を押すことで確定。
これを繰り返し最後に、Submitを押す仕様。

ひとつ前の決定をクリアしたい場合にはClearボタンを、全部クリアしたい場合はAll Clearを押せばよい。

2008年7月14日月曜日

ソース改編

最近更新されてないように見えるShortest Path Graphicだが、いま大きなソース改編を行っている。

先日書いたとおり、経由点を指定できるような仕様に変更している。
1点だけ経由するバージョンを仮に動かしていたが、新仕様では複数点に対応している。

そのためのグラフィック的な仕様から内部の仕様まで大きく変える必要があるため、少々時間がかかってしまっている。

2008年7月13日日曜日

医者

先日医大のオーケストラのOBのオーケストラに参加させていただいた。
市民オケに参加したことはあるが医大関係は初めてのことだったが、医大のOBオケということで実際の医者もいるわけで、医者の知り合いが居るというのは人生長く考えて悪いことではないと思う。

2008年7月12日土曜日

高速道路

経過点にも対応するShortest Path Graphicだが、実際に使ってみると結構離れている道でも同じルートを途中まで通ることが多いのが視覚的にわかる。
今までそのように言われていたのは知っていたが、実際にやってみると改めて思い直すものだ。

2008年7月11日金曜日

使われる道路

3点を入力し、出発点、経由点、到達点での最短経路を表示するオンラインソルバーを非公式に作ってみた。
改良の余地はあり、まだ公開には至っていないが近いうちにこちらに公開されるであろう。

今のところは2回プログラムを起動させ、画像透過を2回行っているだけだがクエリファイルを作り、実行時間を早くするような方針にする。

2008年7月10日木曜日

ログ2

Shortest Path Graphicではログをつけ始めている。
使用しているブラウザも残した方がいいんじゃないかということで、そういった情報も残すようにした。
PHPでは、
http_user_agent= getenv( "HTTP_USER_AGENT" );
で環境変数を取得できるので、これをそのまま出力している。
別にブラウザだけである必要はなく、情報は細かい方がよいので何も処理せずそのまま残している。

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9) Gecko/2008052906 Firefox/3.0
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.8.1.15) Gecko/20080703 Vine/2.0.0.15-1vl4 Firefox/2.0.0.15

こういった形で出力されている。意外にこれだけで細かいことまで調べられることがわかる。


convert時に何かあったか、プログラムの連携などといったログも残したいと思っているのでそちらも随時対応していきたい。
その場合は今のログの残し方の形式を少々複雑にしなければならないが・・。

2008年7月9日水曜日

ブラウザの「戻る」ボタン

ブラウザの「戻る」ボタンで戻るとキャッシュからデータを読み込み、こちらが意図しているような動作をしてくれないことが多々ある。

Shortest Path Graphicでも、Resolutionの値と画像のサイズで異なってしまう現象が発生してしまう。

解決策として、キャッシュを保存させないなどを考えたが、ただでさえサイズが軽くない画像を扱う以上、なるべくならキャッシュから読み込んで欲しいので新しいウィンドウで開くという方法を採用した。

悪くはないが何かしっくりこない・・。

2008年7月8日火曜日

ページ遷移

Shortest Path Graphicでは、入力ページ、計算ページ、出力ページに分かれている。

入力ページ→計算ページは Submitボタンで遷移。
計算ページ→出力ページはheader("location")を使っている。

そもそも入力エラーが合ったときにheader("location")で最初のページに戻れば良かったのだがすっかり忘れていたのでその処理をした。
ちなみにheader("location")はそのページの最後まで処理をするので途中で終わらせるときは
exit;
をつけてやらなければならない。

2008年7月7日月曜日

ログ

ご指摘をいただいたようにこそこそとShortest Path Graphicのログをつけ始めている。

とはいえ、まだまだ簡易版でプログラム側との連携をしていくよう改良していく予定。
今ログからできることは同じ状況の再現のみで実行状況を逐次チェックまではしていない。

色々ファイル状況などと複雑に絡むのでいったんここまでを動かしておいてそこから変更していく方針。
当たり前だが、ユーザー側からは何も変わってないように見えるはずである。

2008年7月6日日曜日

Shortest Path Graphic

気がつけば3000行を超えていて意外に早いものだと思わされた。
実際はIE用を別に作ったり、ブロードバンド版、ナローバンド版で分けていたりするのでそこまで書いているわけではないが。

ソースも汚くなり始めているので落ち着いたら少しずつ整理していきたい。

2008年7月5日土曜日

今後の方針

Shortest Path Graphicの基本的にやりたかった部分の実装は終わっている。
今後は他の人の意見を取り入れての変更が中心になるだろう。

緯度経度に対応して、GoogleMapsとの連携などそういったこともしていきたい。
こちらは共同研究者の方との連携が必須となる。

2008年7月4日金曜日

謎のバグ

宣伝が多いんじゃないかとつっこまれたくなるようなShortest Path Graphic

点を2つ入力して結果を返すんだが、どのような条件かわからないが、最短パスが表示されないことがある。同じ点でもやり直すと結果が出るため原因がわからない・・。

パスが出ないと言うことは、arcファイルとpathファイルを合成するときにpathファイルがないということしかはっきりしていない。
今動いてるのが偶然なのかどうか引き続き検証中・・。そのような現象が起こってしまうときの状況を随時募集中・・。

2008年7月3日木曜日

フルブラウザ

最近の携帯電話にはフルブラウザ機能がついているものも多い。

Shortest Path Graphicのナローバンド版が出たということで今までのバージョンでは画像ファイルの容量の関係で辛かった携帯電話(DoCoMo SH906i)のフルブラウザで動作させてみた。

一番サイズが大きいと言われているNYでも表示させることができるが、PNGファイルの透過に対応していないらしく、パスが現れなかった。
しかたがないので、Downloadボタンとやらを押してみて合成させたPNGファイルを表示させたところ無事パスも表示され、携帯電話でもとりあえず無事動作した。

残念なのはクリックに対応していないため、座標が手入力な所だ。

2008年7月2日水曜日

ナローバンド版

こっそりとShortest Path Graphicのナローバンド版を公開している。
これによって海外でまだまだブロードバンドが普及していないところでも使いやすくなったはず。
幸か不幸か自分でその環境を試しにくいというのがあるが・・・。

今までとの違いは以下のような形となっている。

・地図データの画像ファイルのサイズの基本を1600から800に変更し、それに伴い実行画面のResolutionのMax値を800に。

・結果画面では元の画像ファイルをキャッシュから読み込んでくれることを期待してパスを作ったファイルとの透過にし、読み込む容量が減ることを期待。

・上のままでは画像の保存ができないので別にDownloadボタンを使うことによりそこで2つのPNGファイルを結合して表示させている。

2008年7月1日火曜日

IEにおける座標の取得

Shortest Path Graphicにおいて、jQueryにおいてIEのみ座標指定がおかしくなる話は先日書いたとおり。

調べてみたところIEではスクロールの部分を余計に足してしまったりするらしいのでそれを引いてやらなければならない

if(window.createPopup){
var x = e.pageX - $('#image').position().left - document.body.scrollLeft;
var y = e.pageY - $('#image').position().top - document.body.scrollTop;
}else{
var x = e.pageX - $('#image').position().left;
var y = e.pageY - $('#image').position().top;
}

document.body.scrollLeft(Top)の部分があるのとないのでIEへの対応をしている。
実際にはif文が乱立してしまうのでIEのみ別のページに飛ばして対応している。


参考:http://www.openspc2.org/JavaScript/Ajax/Ajax_study/chapter05/013/index.html

2008年6月30日月曜日

IEへの対応

IEが他のブラウザと違う挙動をしやすいのでIEのみ別のページに飛ばすようにした。

<?php
$HTTP_USER_AGENT = getenv( "HTTP_USER_AGENT" );
if( ereg( "MSIE", $HTTP_USER_AGENT ) ) {
header("location:ie_senyou.php");
}
?>
逆にIEのページからはeregの部分を否定にして元のページに飛ばすようにしたのは言うまでもない。

参考:http://blog.caraldo.net/2007/07/php.php

2008年6月29日日曜日

問題

公開から大きなトラブルもなく微妙にバージョンをあげてきたと思われていたShortest Path Graphicだが、ここにきて、大きな問題が見つかってしまった。

IEでの座標の取得に支障が出ていたのに全く気づかなかった。
小さい地図では問題ないんだが大きな地図や画面を小さくしたときに影響が出る。
なんとかしなければならないが対策が思いつかない・・・。

2008年6月28日土曜日

ナローバンド

日本ではブロードバンドが普及しナローバンドはあまり見なくなった。
しかし、海外ではまだまだそういった環境も多いためShortest Path Graphicでは海外ユーザーのためにそのような環境も作成する予定。

現バージョンとの違いは以下のようにしようと考えている。

・1600の解像度の画像を800に変更。
・結果ページにおいて、現在はpngファイルの合成をしてから表示しているが、少し前に書いた透過の技術を用いて実装。

解像度を落とすのは根本的対策で、結果ページの方法はキャッシュから画像を読み込んでもらうことにより、表示を早くしようという考え。

また、時間がかかってもいい人用に解像度3200といったものを用意してもいいかもしれない。

2008年6月27日金曜日

VMware-toolbox

VMware-toolboxがインストールされていると、ホストOSとのコピペができたりマウスの透過ができたり非常に処理がしやすくなる。

インストール方法は1年前くらいに書いているので省略するが、自動実行するには
Vine4.xにおいてはtoolboxを起動したいユーザーで
デスクトップ→設定→高度な設定→セッション
で自動起動するプログラムのところに
/usr/bin/vmware-toolbox

とすればよい。自分の場合別のワークスペースに移してしまうのでこのままだが、最小化したければ

/usr/bin/vmware-toolbox --minimize

としておけばよい。

2008年6月26日木曜日

画像の読み直し

今までは画像の大きさ変更をページごと読み直しPHPで実装していたがJavaScriptを用いて実装した。

ちょっとした事情があり結果画面のみにしか採用していない。
将来的には入力画面でも採用することになると思うが、地図自体の変更には採用しない予定。

余談だが今回もIEだけがなかなかうまく動いてくれなかった。
やはり、ブラウザごとにコードを書くようにしたほうがいいのかもしれない。

2008年6月25日水曜日

ブラウザ

先日ブラウザによって挙動が違うという話をした。
そのときはSafariが厳密に読んでくれたのがいいのか悪いのかはわからないがSafariのみ対応していないという状況であった。

今回はIEが読んでくれない現象が生じてIEだけ対応できないという状況になってしまった。
これに関してはnameを指定していなかったからなのだが、残り2つのブラウザはこれらを考慮して読んでくれていた。一つしかないのならこれを読んでほしいものだが、まぁ仕方がない。

Ajaxが流行ってきているが一番の問題はこういったブラウザ間で挙動が違うクロスブラウザ問題を考慮しなければならない。
とはいえ、ブラウザを何個もインストールしているのはちょっと悲しくなる。

2008年6月24日火曜日

Windows Update

自分のブログによくWindows Updateができないというトラブルで流れてくる人がいる。

エラーのログが「%windir%/WindowsUpdate.log」(ファイル名を指定して実行で打ち込めばよい)というところにあるので、そのエラーナンバーを確認する。後はそれを適当に検索をかければよいでしょう

0x80004002に関しては昔自分も書いている。

%Windir%\system32\net.exe stop bits
%Windir%\system32\net.exe stop wuauserv
%Windir%\system32\regsvr32.exe atl.dll
%Windir%\system32\regsvr32.exe jscript.dll
%Windir%\system32\regsvr32.exe msxml3.dll
%Windir%\system32\regsvr32.exe softpub.dll
%Windir%\system32\regsvr32.exe wuapi.dll
%Windir%\system32\regsvr32.exe wuaueng.dll
%Windir%\system32\regsvr32.exe wuaueng1.dll
%Windir%\system32\regsvr32.exe wucltui.dll
%Windir%\system32\regsvr32.exe wups.dll
%Windir%\system32\regsvr32.exe wups2.dll
%Windir%\system32\regsvr32.exe wuweb.dll
%Windir%\system32\net.exe start bits
%Windir%\system32\net.exe start wuauserv

これをコピーして
ファイル名を指定して実行→cmd→でDosの窓が出てきたら貼り付ければ全部順番に実行してくれる。

昔書いたブログが役に立ってしまったというのはここだけの話だ・・。
そしてこのOSは自分のアップデートもうまくできないのですね。

参考:http://d.hatena.ne.jp/Gazebo/20070802/p1

2008年6月23日月曜日

意見

様々なユーザーから意見をいただいているShortest Path Graphic

海外ではナローバンドの回線も少なくないので、そういったバージョンも作った方が良さそうだ。
また、逆に高解像度版を用意してUSAでの楽しさも体感してもらうのもおもしろいかもしれない。

ただ、自分が負けず嫌いなのもあるが「ナローバンドの方はこちら」と書かれていても動作に影響がなく遅いだけならブロードバンド版の方を選んでしまう気もする。

2008年6月22日日曜日

高速化

今までUSAのグラフになると1分前後かかっていたShortest Path Graphicだが、10秒以内に解けるようになっている。
元々計算時間より、グラフデータの読み込みの時間が多かったため、それを削減した形。

現在はファイルを使い回しているため、表示のページを更新すると後から使用したユーザーの結果が表示されてしまうことがある。
今後の方針としては、クエリ番号をつけてユーザー数に応じて出力ファイルを残しておく予定。

2008年6月21日土曜日

ユーザー視点

知り合いの大学1年生(理系)にShortest Parth Graphicを使わせてみた。

使い方以外の前情報を与えずにやらせてみたところ、USAを最初に実験していた。
やはり一般的に大きい地図の方が興味があるのだろう。

「山道などの速度は考えているんですか?」
と質問されたが、これは最短路なので距離が最小のものを出している。
とはいえ、グラフファイルには高速道路等を加味したものもあるとのことなのでいずれそちらにも対応するだろう。

余談だが、ブックマークしてくれたそうだ。

2008年6月20日金曜日

Shortest Path Graphicのバグ

公開時点でSafariで表示できないことをすっかり忘れていた。

携帯電話のフルブラウザでもやってみたが、できなくなっていたのに気づき(当初はできた)ソースを見直してみるとHTMLのタグのミスであることが発覚。
修正したところSafariでも携帯でも表示できることを確認。

間違ったタグを無視してなかったことにして読み込むブラウザがいいのかそれを厳密に解釈するブラウザがいいのかは別としてHTMLはエラーメッセージとかがでないので開発は非常にやりにくい。

2008年6月19日木曜日

Shortest Path Graphic

準備を進めていた最短路問題におけるオンラインソルバーが公開できる程度になった。
http://opt.indsys.chuo-u.ac.jp/portal/
で試すことができる。

まだまだ試作段階のため改良点は多い。同一の地図で複数ユーザーがアクセスすると2人目以降のアクセスはブロックしてしまうので実行に時間がかかるUSAの実行ではビジーになりやすいので注意していただきたい。

また、FireFox3ではWebページの座標で10程度のずれが生じてしまう。(v2では問題なし)

Shortest Path Graphic使用方法
画像の好きな点2つをクリックし、座標が2つ入力されていることを確認する。
Submitをクリックして計算するのを待てば最短路が書かれた画像が表示される。
この画像は右クリックの画像を保存などでローカルに保存することもできる。

2008年6月18日水曜日

Firefox3

が正式リリースされました。
サクサク動いていい感じです。
24時間ダウンロード数のギネス記録を狙ってるらしいので興味のある方は日本時間19日午前2時までにダウンロードしてみてはいかがでしょうか。

2008年6月16日月曜日

ShortestPath Online

をこっそりと昨日から仮サーバーで動かしている。
サーバーも実際に稼働予定のマシンにうつしてみて実行・・!

と思ったがどうも変数の受け渡しがうまくいかない。
結局php.iniの設定の問題であったがマシンが違うとそういうところも気を付けなければならない。

2008年6月14日土曜日

副都心線

たまたま用事があったのでさっそく副都心線に乗ってみた。

和光市→小竹向原→池袋→新宿三丁目→渋谷

というターミナル駅?しか停車しない急行は悪くないと思う。
途中駅を通過するときは当たり前だが、減速するようだ。

和光市民あたりはあまり変わらない印象だが、和光市から埼玉方面の東武東上線沿線は意外に便利になるのかもしれない。

2008年6月13日金曜日

gfarm v2

v1のときに問題のなかった
config-agent
がエラーで止まってしまう。
/usr/local/bin/config-agent: line 232: mkcnf_agent_sysdep: command not found
/usr/local/etc/gfarm.conf: updated
created /etc/init.d/gfarm_agent
added gfarm_agent service
Starting gfarm_agent:/usr/local/bin/gfarm_agent: symbol lookup error: /usr/local/bin/gfarm_agent: undefined symbol: GFARM_ERR_NO_SUCH_OBJECT [failed]
config-agent: cannot start gfarm_agent
config-agent failure

ちょっと調べてみるとfuseかglibc-not-hiddenを入れなければならないらしいが・・。
逆にv1のときはなぜ動いていたか疑問になる。

config-agentが実行できないため
gfrun,gfgrep等のコマンドも
gfrun: symbol lookup error: gfrun: undefined symbol: gfarm_spool_server_port
gfgrep: symbol lookup error: gfgrep: undefined symbol: gfs_pio_get_node_rank

等が使用できない。どうしたものか・・。
fuseもCentOS5版があればいいのだが。

2008年6月12日木曜日

GFarm2のインストール

GFarm2のインストールに戸惑っていたがとりあえず解決した。

v1に比べて若干変更があったようで、
http://filesystem.g.hatena.ne.jp/n314/
を参考にさせていただいた。

gfarm2.1.0というフォルダがあるとする。
cd gfarm2.1.0
./configure
make
sudo make install
ここまではv1と変更がない。

config-gfarm -t(root)
で問題なければ
config-gfarm(root)
を実行。
この時PostgreSQL等が起動していたらエラーが出るので
ps -ef | grep postgre
などでプロセスを確認してkillすればよい。

v1はこのままconfig-gfsdを実行していたが、
v2の場合、
gfhost -c -a x86_64-centos5-linux -n 4 -p 600 ore00.optsys.xxx.ac.jp ore00(user)
を先に実行する。
useradd -c "Gfarm gfsd" -m _gfarmfs
した上で、
config-gfsd -t
間違いなければ
config-gfsd
で完了。
gfhostについても-pでポートを指定しなければならなくなったようだ。
また、そのままで全てのユーザーで使えるわけではなく、
gfuser -c hoge hoge /hoge ""
のようにユーザーを登録しなければならなくなった。
また、config-gfarmを実行したユーザーのみはこの作業は不要である。

2008年6月11日水曜日

htmlで画像を重ねて表示

ご存じの人も多いかと思うが、PNGやGIFといったファイルは「透過色」なるものが用意されており、後ろが透過して見えるような色(?)を使うことができる。

故に画像を重ねれば見た目合成したようにすることができるのだが、単純にhtml上にImgで並べるだけでは合成されない。

<img border=0 src="gazou.png" width=400 height=400 style="position: absolute; top:0; left:0;">
<img border=0 src="sitagasukeru.png" width=400 height=400 style="position: absolute; top:0; left:0;">

<>をhtmlタグとして認識されてしまうらしく、全角で表示しているのでコピペする方は注意していただきたい。

のように強制的に位置を決めてやってしまえば良い。
上の例だと上から0,左から0の位置に400x400で表示するという設定。

スタイルシートに書いたけどうまくいかなかったので直接貼り付けたのはここだけの話。

2008年6月9日月曜日

座標を渡す その2

前回別ページを用意して解決する方法を書いた。
落ち着いて考えるとそもそもPHPを使えばjavascriptに変数を渡すことは可能なのでそこをif文にすることにより1つのファイルにすることにした。
1つのファイルになっただけで、実質的には自分のページ自身を再度呼び出しているに過ぎない。

その他の部分も修正し、見た目が前の2つ用意していたときと全く変わらなくなった。

実行ページではまたいろいろと別の処理をしなければならなそうなので別ファイルにしたままにした。

2008年6月6日金曜日

座標を渡す

先日の座標を取得するプログラムの件だが、一応の解決はした。
元々最短路問題において出発点と到着点を取得するのが目的であったのだが、1点のみの座標取得は容易にできるのに対し、その情報を保持しつつ2つめの点の取得にはいろいろと条件がかかってしまっていた。
JavaScriptでは静的な情報しか保存できないのが厄介。


その問題は以下のようにして解決した。


ほとんど見た目が変わらないページ1とページ2とページ3を用意する。

ページ1において座標を取得。
決定ボタンをおき、出発点の座標をページ2にわたす。

ページ2において到達点の座標を取得する。
出発点の座標はこの時点で変数に格納されているため失われることはない。
決定ボタンとクリアボタンを置き、決定ボタンを押すと二つの点の座標をページ3に渡す。
クリアボタンを押した場合はページ1に戻る。

ページ3ではそれらの座標を使って処理すればよい。


これにより問題なくプログラム側に座標を渡すことは可能になった。

グラフィック的に点をクリックするとそこが塗りつぶされるとかそういう効能があるとベストなので改良の余地は多々ある。
見た目的にもわるすぎるのでそのあたりも考慮しなければならない。

2008年6月4日水曜日

PHPとJavaScript

研究の関係でブラウザ上で画像のクリックした部分の座標を取得するプログラムを作らなければならない。

JavaScriptでの座標取得は比較的容易にできる。
しかし、その後にPHPで作業をするためにPHP側の変数として扱うためには$_GETや$_POSTを用いてページをリロードするしかない。

当たり前の話だが、PHPの変数をJavaScriptに与えるのは容易である。

2008年6月3日火曜日

GFarm2.1.0

がリリースされたそうなのでインストールしてみるが、

config-gfarm

を実行するとPostgreSQLの開始時にエラーが出る。

ps -ef grep postgre

をしてみてもプロセスは消えているんだが・・。

1.4でも大きな問題は発生していないのでしばらくはこっちを使っていよう・・。

2008年5月28日水曜日

あっさり進行

無事クラスタ内では解決したので別の実験用オンラインソルバーのマシンにもGFarmをインストールしてみた。

./configure
make
sudo make install

といつもの感じであっさり終了

config-gfarm -t
config-gfarm

config-agent -t
config-agent

config-gfsd -t
config-gfsd

あっさり終了。

gfhost

にて自分自身は認識しているのを確認。

/usr/local/etc/gfarm.conf

をクラスタの方のgfarm.confにコピー。

クラスタの方の.gfarm_shared_keyを実験用マシンにコピー。

gfhost

にてクラスタと、実験用マシンの両方を認識していることを確認。
あっさり行きすぎて怖いがここまでは問題なし。

とはいえ、問題がないわけではなく
オンラインソルバーから使用することになるため今のままだとapacheユーザーを使わなければならない。良い方法がないかどうか考え中。

2008年5月26日月曜日

24時間制限

だいぶ前(3/19)にも書いたが、Gfarmにおいて

gfkey

で作成されたキーは24時間しか持たない。MAX24時間でそれ以上はもう一度作り直さなければならない。それを回避するために

gfkey -f -p 200000000

が使えるかもというのを実験してみたが予想通り(?)問題なく24時間後も動作している。
ちなみに本当にこの時間で鍵が切れるかは2315日経ってみないとわからない。

現実的にセキュリティを考えると1か月に1回くらいはリブートもするだろうしその都度鍵ファイルを作り直すのがいいだろう。

前回書いた

connection refused

のエラーについてはただgfsdのサービスを起動してないという基本的なミスでした・・。
いろいろ疑ってかかって問題解決に時間を食ってしまった・・orz

2008年5月24日土曜日

変更

オンラインソルバーのページ設定をしばらく続け、各ソルバーをプルダウンメニューで替えるようにした。
前に書いたかも知れないが各ソルバーには極論を言ってしまうと
バイナリ(+オプション)、インプットファイル、アウトプットファイルの3種類しかないため、そこの部分だけを考え全部共通仕様になっている。
実行ページ、ファイル管理ページは問題なく動作はするはずようにはなっているはず。
後はちょこちょこ変更していけばこっちはそれほど問題にならないだろう。
大きく直さなければならないのはログの管理くらいか・・。
それにしてもPHPはコンパイルがないし、html文も入ってたりで括弧が山のようになりエラーの場所を探すのが面倒だ。

そんなところでいったんこちらには見切りを付けてGfarmの方に戻ってきた。
接続できないという問題は解決しいざ色々と実験しようかと思ったら次の日にまた接続できなくなった。
パス認証の問題ではなくconnection refusedになる・・。
おそらくすぐに解決すると思うので
オンラインソルバーの実験用サーバーにもGfarmを入れて、実際に実行可能かを試す段階までなんとか週末でやりたい・・。

2008年5月1日木曜日

簡略化

Gfarmがどうもうまくいかないので最近は気晴らしもかねてPHPの方の作成をしている。

だいぶ前にも書いた通り最適化オンラインソルバーの運用に向けて、

1,ほとんどのソルバーにおいてほぼ同じような使い方ができる
2,ソルバーを追加する作業を簡略化する

の2点を中心に進めている。
各ソルバーには設定ファイルが用意されており、そこに使用する計算機、パラメータの種類等を記述する。それに従ったフォルダを初ログイン時に作成し、メインページではその設定ファイルに従ってファイルを読み出すことになる。

ソルバーを登録するときはその設定ファイルと実行ファイル(バイナリ)だけ用意すればできるのが最終目標であるが、ファイル実行時には様々な制約がかかりそこの部分だけはまだ考慮する必要がありそうだ。

今回行っていた作業は元のSDPAのメインページより、共通部分をPHP化し、設定ファイルを読み出すことができるようにした。
これによりパラメータ等が何個であってもソルバーに応じてループ文で対応できる。

ログの残し方、実行時のメールの送信をどうするかなど細かい面も詰めていってもいいかとおもう。
先生にも言われてるようにインターフェイスをどうするかが結構課題・・。

GWくらいで見切りをつけ、Gfarmの方も再開せねば。

2008年4月11日金曜日

ホストの追加方法

Gfarmにおいてホストを追加するには下のようなコマンドを打てばよい
x86_64やCentOS5の部分は環境によってはもちろん変更する。

gfhost -c -a x86_64-centos5-linux -n 4 ore01.optsys.xxx.ac.jp ore01

面倒だが、登録数分やらないとたぶんダメである。

設定が完了すれば

gfhost -l

で細かく見ることができる。

0.06/0.02/0.00 s x86_64-centos5-linux 4 ore00.optsys.xxx.ac.jp(xx.x.x.xx)
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore01.optsys.xxx.ac.jp(xx.x.x.xx) ore01
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore02.optsys.xxx.ac.jp(xx.x.x.xx) ore02
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore03.optsys.xxx.ac.jp(xx.x.x.xx) ore03
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore04.optsys.xxx.ac.jp(xx.x.x.xx) ore04
x.xx/x.xx/x.xx - x86_64-centos5-linux 4 ore05.optsys.xxx.ac.jp ore05

最初の部分が
-.--/-.--/-.-- -
のときはポートが閉じている場合や認証が通らない場合などに起こるのでそちらの設定を見直す。

x.xx/x.xx/x.xx
のときはそもそも存在しないか間違っているかなのでもう一度ホストの設定を見直す必要がある。
上の場合はおそらくore05というのが存在してないと推測できます。台数の勘違いでしょう。

自分のように-.--/-.--/-.-- -のときにホストをいくらみても解決しないとならないように気をつけたい。
普通にマニュアルに書いてあることですけど。

2008年4月3日木曜日

復旧作業3

どうやら電話での聞き間違いだったらしく1つのHDDがまた逝ってしまわれたようであった。
新しいHDDを購入し、とりあえず復旧。

オンラインソルバーに関しては先生が昨日再クラッシュの前に昨日の作業のバックアップを取っておいてくれたのでほとんどコピーするだけで終了。
何か忘れてる気がするんだが、思い出せない・・。

2008年4月2日水曜日

復旧作業2

新しいHDDに変えた上で復旧作業をするわけだが、設定ファイルとwww以下のデータファイルさえコピーすればおそらく問題ないであろう。

昨日の復旧中で分かったことだがPHP4→5にするとどうやら変数の扱いが微妙になるらしく、ユーザーから受け取った値を直接printすると警告が出る。
htmlspecialchars()を使えばいったん変換されるので警告が消える。特殊文字など使ってないとは思うのだが・・。
MySQLのデータベースの移行はコマンドがあるらしいが普通にvar以下にあるようなコピーして持ってくるだけでも問題なく移行はできた。あまり推奨はされてないのかもしれないが・・。

復旧作業

オンラインソルバーのメインマシンのHDDの調子が悪くなり、昨日の夕方くらいにSSHすらできなくなり4台のHDDのうち/以下を担当する部分がクラッシュ。。
朝3時過ぎまでの復旧作業の末見た目等は全て戻ったはずであったがやはり調子が悪いらしく今日他のドライブも逝ってしまわれたようだ。

2008年3月19日水曜日

Gfarm

optクラスターを5台ほどいじっていいということでGfarmをインストールしてみることにした。
鍵のデフォルトの時間が24時間で毎回更新しなければならないという感じではあったが
gfkey -f -p 200000000
とかで回避できそう。それを実験しようかと思ったが、落ちついて考えると全部NFSでHOMEがファイル共有されてる気が・・。

就職活動

就職活動も一段落したので研究の方にぼちぼち戻ります。

就職活動をして色々勉強になりました。(一応まだ継続中ですが・・。)
企業側から見るとそのときの能力云々よりも会社に合う人や一緒に働きたいと思う人を採用するのかなと思ったりする。
あまりにも能力が高くてある程度コミュニケーションが取れれば話も違うのかもしれないが。

2008年2月8日金曜日

現行からの変更点(予定)

現行のままでは不便が生じるのと管理者が変わったときに大変なので以下のように変更することが自分の中ではほぼ決定。

今のmain.phpは
solver/sdpa/main.php
に移動して管理する予定。
元の場所のmain.phpは各種solverへのリンク集みたいなのと情報ページみたいになるのかな・・。

というわけでShortest Pathであれば、
solver/shortestpath/main.php
になるわけで

基本的にmain.phpというファイルは変数で書けるものは変数で書いてなるべく同じ書式にする。
基本フォーマットにはソルバーに関係なく使えるようなサンプルファイルを用意する。ソルバーの追加や変更を容易にするのとユーザーから見てフォーマットが似てる方が使いやすいという二つの意図があり。
それに伴い、共通の設定は別にcommonファイルを用意。ソルバー独自の設定が別に必要だがなるべくmain.phpのファイルをいじらないで別のphpファイルから読み出せるようにしたい。
最終的な決定は何種類か最適化プログラムの仕様が分かってからにならざるを得ないが・・。

それと前の更新で書いた一方を採用し、
userdata/username/solvername/data(param)
フォルダに入出力データを入れることに変更。
そうしないと一括管理が非常に難しくなるのと、input,output系のファイルが複数にわたるときの管理が面倒になるという理由があり。
今現在、初ログイン時に、必要なフォルダをmkdirコマンドを呼び作成しているのだが、そのままの仕様にするなら作成するフォルダの一覧を変数にして別のファイルに用意しておいた方が良いかな。

インターフェイスも変えたいがこういった仕様を先に決めておかないと後が厄介なのと自分に美的センスがないのとで結構悩みどころ・・。

2008年2月4日月曜日

フォルダの変更

オンラインソルバーを実際に稼働するときにはソルバーが今までのようにSDPA1個ではなくなるのでファイル管理の方式を変えなければならない。

今は一つのフォルダの中にパラメータのフォルダ、データのフォルダになっているのを
param/"solver_name"/
data/"solver_name"/
のように変更するつもりだ。このくらいの変更ならすぐにできるので問題はないはず。
問題があるとすればあるかわからないが他にファイルが必要になるソルバーだろう。あったとしてももう一つフォルダを作るとか逆に
"solver_name"/param/
"solver_name"/data/
"solver_name"/nannka/
のようにすれば良いだろう。
拡張性という意味では後者の方がいいかもしれない。

現行では、初ログイン時に、パラメータとサンプルファイルをコピーしているがこの処理を移項するまでは新フォルダと旧フォルダに両方コピーするようにしておこうと思う・・・。

2008年2月1日金曜日

インターフェイス

オンラインサービスにおいてインターフェイスというのは重要な存在で、技術的でなくても優先順位は高い方になる。美的センスのない自分がどうするかというのは色々考えているが・・。

それはさておき、なんにせよ実際にオンラインソルバーを動かすときも今と配置を結構変えなければならない。左の方にソルバーのリストを置いておき、使用するソルバーのページに飛んでもらって問題を解く形式にしようと思うが。

ほぼ同じような処理で使えるようにしたいので、今何のソルバーを使おうとしてるのかを明確にどこかに表示しないと間違って違うソルバーのページに飛んでしまったときに問題が見つからない等のトラブルでイライラしてしまうだろう。

ファイル管理もソルバーごとにフォルダを作った方がいいだろう。
その方がユーザーも管理しやすいであろうしいいと思うのだが、「グラフ」などの共通の問題に対して何回もアップロードさせるかどうかはちょっと考える余地がありそうだ。ソルバーの入力形式に依存するのでその辺も考慮しなければならないがそこまで共通の書式を取れることは少ないだろうなぁ。

2008年1月24日木曜日

中間発表

今日は中間発表で一応時間オーバー等もなく無事終えることが出来た。
結局インパクトのあるスライドも準備できなかったのは心残りではあるが1年後心残りがないようになっていればいいと思って切り替えよう。
それにしても発表とかはなかなか慣れないものだ・・。

2008年1月16日水曜日

就職活動

今日は学内でセミナーがあったので2社ほど説明を聞いた。
学部時代も就職活動はまったくしなかったためこういう経験すらほとんどないので新鮮であった。
とはいえ説明会で自分の会社の悪いことを言うことはほとんどないのでそのような中で良い会社を選ぶのはなかなか難しい。