今度はTipsではなく、内部コードの変更です。
6%程度の高速化しかできなかったですが…。

英語版ドキュメント等を用意する余裕がないので言及してませんが、Location::GeoToolには動的に経緯度記述フォーマットや測地系、方位角毎の方角名を動的にユーザ定義できる機構があります。
追ってまたドキュメントも揃えますが、興味のある方はソース中のset_original_format、set_original_datum、set_original_dirstrあたりを覗いてみてください。
で、その機構を備えているために、動的に追加された測地系やフォーマットにもdatum_xxx、format_xxxといったメソッドで対応するため、実はその手のメソッドは全てAUTOLOADで対応しておりました。

Location::GeoToolの動作の重さがどうにかならないかという事に関して、利用者の方から示唆をいただいたりした事も有り、ちょっといくつか試して見ました。

その1としては、オブジェクトの生成に時間がかかっているのではないか、という指摘。
1つ2つの経緯度処理なら全く問題ないのだけど、何万何千と言う位置情報を処理するのに、いちいちオブジェクトを生成していては非常に処理が遅くなるのが問題。
解決方法としては、Jcodeのsetメソッドのように、オブジェクトの生成は行わずに、既存オブジェクトの中身だけ置き換えるメソッドを準備すれば、早くなるのではないかという示唆があって、実際示唆してくださった方はそういう拡張を行ってテストしてみてくださったのですが、100万件回して、毎回オブジェクト生成だと30秒弱、使いまわしだと10秒弱ですんだ、との事。

さっそくその結果を実装に反映しようと見てみると…随分前に作って忘れてたけど、よく見るとコンストラクタのcreate_coordって、クラスメソッドとしてもオブジェクトメソッドとしても呼べるように作ってあるわ…。

sub create_coord3d
{
my $self = shift;
$self = $self->_new() unless (ref($self));　<-このあたり
@{$self}{qw(lat long alt def_datum def_format source)} = @_;

というわけで、1つ目のLocation::GeoTool高速化としては、モジュール側の改造ではなく利用者側のTipsとして、
・大量の点を処理する場合は、create_coordオブジェクトはクラスメソッドとして呼ぶのではなく、オブジェクトメソッドとして、オブジェクトの使いまわしをする事
という結果が判りました。

Perl関係の調べ物していて、行きついたサイト経由で、面白いソフトをみつけた。

Workrave

実行すると常駐して、3分に1回の十数秒の小休止、45分に1回のコーヒーブレイク、4時間に1回の散歩の時間等、計測してリマインダーとして動いてくれる(時間はもちろん推奨時間であって、自由に設定可能)。
私もいろいろと持病持ちなので、ある程度気を付けないとヤバイので、さっそく入れてみた。

しかし3分に1回の休みは休みすぎ?と思わないでもないが、コーヒーを45分に1回は我慢できないぞ。
せめて15分に1回にできないか(だから設定変えられるって)。

味の素が粉末の出る口の穴を大きくして、使用量が増えるようにして売り上げを伸ばした、というのは、都市伝説的なので事実なのかどうかは別として有名な話ですが、
最近あるインスタントコーヒーの詰め替えパックって、似たような効果があるんじゃないか？と思いました。
容器代がいらず安くなるので売る側にも買う側にもメリットがあるわけですが、それに加えて、メーカ側が意識してるかどうか判らないですけども、上の味の素の例のような「無駄遣い促進」効果があるんじゃないかと。

Class::DBI、ここギコ!の鬱陶しいと言うか、小癪なと言うか、こまっしゃくれたと言うか、どう書いても意味不明なわけですが、そんなDB構造をいきなりClass::DBI初心者が展開しようとして、なんかリレーション部分とかの動作が不安で面倒臭いなー、とか思ってたわけですが、

もっと単純な案件に適用して、生産性向上度合いに驚いてしまいました。
これはすごいでつね。

会社の仕事で、着うたサイトなんですが、外注に出してなんともかんともな仕上がりで帰ってきた代物を、操作性や保守性向上のためにぼちぼちとリファクタリングしてるんですが、DB構造は単純なんで、こいつでClass::DBIの練習でもしてやるかと思って、着うたのいろんな方式での検索部分に適用してみました。

前のGIS実験?を見てくれた元GIS系の知人から、球面を意識しているのが面白い、と感想をいただいた。
逆に、GISにそんな事大して必要ないだろうに、何をつまらん事やってんだか、と思われた方もいるのかなーとも思ったりする。

なんでこんな事やってるかっていうと、GISの世界が蓄積してきたノウハウ・資産を活かさないと、とは思っているものの、別にGISそのものをやろうとしているんじゃないからなんですよね。
俺のやる事(というか、正確にはうちの会社のやる事ですが。俺はむしろ、Googleでの地名検索→経緯度変換だって位置情報だと思ってるし、どんな発想にも縛られたくないので)としては、SpaceTagの概念を見てもらえば判るけれども、領域を持ってしかも自発的に動き回る位置情報なんですよね。

点情報で、固定あるいは動き回るにしても動態管理とか実世界で動く現実を仮想でトレースするような要件だったり、あるいは領域を持った情報であっても、動かずに固定で、地図との重ねあわせだけが問題であったり、といった要件なら、その固定点で現実との誤差が少なくなるようなポリゴンのポイント取りをしてやれば済むんだろうけど、
うちみたいに大きさを持ったものが自由自在に、自発的に動き回って、そのリアルタイムな衝突判定もしなければいけないとなると、単純に経緯度で領域管理してると、緯度が大きく変わるように動けば領域がひしゃげるし、正方形で領域設定したつもりがサイズが大きいと実は扇形だったり、大圏コースと直交座標系との誤差でぶつかってるはずなのにぶつかったと判定されなかったり、といった話になるので、どうしても直交座標系で扱った時と現実との誤差にセンシティブになってしまう。

kokoはひまとかblogすればよかった？


*このエントリは、こうさぎの「koko」が書きました。

0と1の狭間に生きる日記

すごい人もいるものです。
上のサイトで開発中の「電猫」と言うシステム、PDA上でGPSから得た現在地を元にルート検索を行うというもののようなのですが、開発言語がPerlというのも驚きですし(というかPDA上で動くPerlあったのか)、もっとびっくりしたのは、探索対象となる数値地図を、ラスタ画像からの画像処理による点群抜き出しによって行おうとしているところ。
すごい。
その技術力と力技に脱帽です。
私も、今の世の中での地図の手に入らなさに嘆いていたくちなので、何度かラスタ画像を処理してやろうかと思った事がありましたが、そんな技術力なかったのと、苦労したって地図上の文字等に寸断されてどうせまともな地図は出来ないよ、とやる前からやらない言い訳を考えてしまうようなアレなので、とても実行に移すような行動力は持てませんでした。

もっとも、そのラスタ解析地図によるアプローチをあきらめる可能性も示唆されていますが…。
それにしたって、それだけの事をやろうとする力があればどんな形にしろ結果を残せそうですね。
期待です。

Posted with ecto

1日2回寝る2重生活がすっかり定着してしまった。

地元関西を離れて、親や親戚の手が借りられない東京に住み始めて半年、何でも家族だけで回さないといけないので、必然家事も夫婦分担。
子供の寝かせつけは私の仕事なわけなんだけど、
2歳始め位までは布団に寝かせて、絵本を読んでやったり歌を歌ってやったりして、徐々に声をゆっくり小さくしていくとかの小手先テクで数十分で寝てくれた。
でも自我が生まれてテレビを見る事や一人で遊ぶ事も覚えて、の今はそう簡単には寝てくれず、下手したら毎日1時間1時間半と寝かせつけに付き合ってやらないと寝てくれない。

そうすると、こっちも疲れているので必然的に寝かせつけると同時に自分も寝てしまい、そのまま2時間3時間。
すると1時〓2時くらいに目が覚めるので、研究や1週間分の炊事で徹夜するのでない限りその頃寝に入る家内と入れ替わりで起き出し、仕事の残りやここギコ開発等に時間を割く。
そのまま起きている事もあるけど、さすがに夜ずっと作業してると眠たくなってくるので、4時〓5時くらいに布団に入り、また2〓3時間寝て、７時〓8時頃起床、家内と2人で子供を保育園に送り出すための朝の戦争状態の後、10時〓11時頃出社。
というふうなライフサイクルになってしまってる。

昨日のエントリーで書いた実験

東経135度北緯35度〓東経136度北緯35度間を線分で結んだとして、実際の地球上では、大圏コースを通るから東経135度30分北緯35度よりちょっと北、の地点は、この線分の南側にくるはずだけど、直交座標系で計算するとこの点は線分より北側になってしまう。
PostGISはどう判定するんだろうか(おそらく後者だと思うけど)。
また実験してみないといけないですね。

結果は、PostGISが直交座標系で扱ってると判った以上当たり前っちゃあ当たり前だけど、後者でした。

Class::DBI関連のネタ探してて新しいBlog発見。
hori-uchi.com

プチ目うろこなネタがいくつかありました。

続・君ならどう書く？（Sledgeを使って作ってみました。）
ソースを見てみる。
おお、post_dispatchメソッドって、こういう時に使うのかー！
全然思いつかなかったよ。

SledgeでのURLエンコード
Template-Plugin-Jcodeか、なるほどこりゃ超便利。
オブジェクトのバーチャルメソッドとして呼び出せるあたりがいいですな。

しかしみんないろんなネタよく知ってますなー。
これだけいろいろノウハウ知ってたら生産性も桁違いなんだろうなー。

Posted with ecto

以前のエントリで

Class::DBI的なアプローチができれば劇的な工数削減ができてとても理想なんだけど、現状のClass::DBIでは1オブジェクト=1テーブルなので、複数テーブルが連合して(=継承して)1オブジェクトになるような構造は扱えない。
というか、Class::DBIを拡張して複数テーブル間のリレーションを内部管理して、1テーブルからなるClass::DBI継承クラスを継承して、2テーブルからなるクラスを作成→さらに継承…なんて事ができる構成を考えようと何度もしたんだけど、その度に挫折。

すると、Class::DBI開発者自身のWikiを発見。
いろいろと読んでみる。
考えて見れば、Class::DBIの使い方って、雑誌の特集記事なんかで紹介されているレベルの事と、そこから拡張したかった時にオンデマンドでの必要部分斜め読みしかしてなかった。
よく見てみると、1テーブル=1オブジェクトにしかできない基本構成は固定だけど、関連テーブルを間に挟んでの多対多のリレーションとかも表現したり、できるみたい。
トリガ機能とかもあるみたいだし、Class::DBI自体を継承して考えて入るような構造を作るのは無理でも、Class::DBIオブジェクトを自作クラスの属性オブジェクトにして、複数テーブル間の関係をトリガや多対多リレーションでうまく表現してやれば、何となく作れそうな気もする。

また、遊んでみるか。
とか書きつつ、他にもいろんな事で「遊んでみるか」と書いてんのに時間が全然割けてない訳だけど。

Posted with ecto

一部ながらケータイ版復活して1週間、時々重い事があったり私が作業してたりとかがあっても比較的順調に動いていたが、久々にハードに鯖落ち。
原因は、セッション管理等の部分から徐々にPostgreSQLに乗り換えつつあるが、MySQLと違いPostgreSQLは追記式のDBなので、データを「論理的」に削除しても「物理的」には削除されないので、パフォーマンスを維持するには定期的にデータ領域を開放する必要があるにも関わらず、その必要性に気付いていなかったのが原因だ。
頻繁に更新されるセッションテーブルで領域を開放しないまま1週間も運用してれば、そりゃ止まりますわな。

一旦セッションテーブルを空にしようとDELETEをかけても、「論理的」には4000件そこそこしか入っていないのテーブルの全件削除に、完全にWebサーバも落として削除以外の負荷を完全になくしても、20分近い時間がかかったのには泣けてきた。
領域開放にさらに10分。
4000件でほぼ半日分のセッションデータなので、多分1週間分の6万件近いセッションデータの残骸が残っていたのだろう。
合計30分+αくらいは、Webサーバを完全に止めてた。
ここしばらく、負荷で接続しにくくなってたり、更新反映のために再起動かけたりといった事はあっても、Webサーバを止めた事はなかったので、ちょっと悔しかった。

思わず関西弁ですが。

PostGIS上での経緯度の距離計算ですが、よくよく拡張関数リストを読んでみると、distance_spheroidなる関数が。
説明を読むと、「再投影もせんと距離が欲しいちゅうような不埒な輩はこの関数でもつことったらええがな」というふうに書いてある。
2点の座標と回転楕円面の設定を与えてやれば、距離を出してくれるらしい。
なんで測地系指定してるのに回転楕円面を与えてやらないといけないのか判らないが(もしかしてアホな事書いてる?)、とりあえずこいつでいけそうだ!

PostGISを触っているが、PostgreSQLをちょっと触ったせいで、基本的な発想自体は判った。
MySQLを触っていた身で、PostgreSQL自体を勉強せずにPostGISのマニュアルを読んでいたので、SQLが拡張される、という感覚がよく判らず敬遠していたのだが、PostgreSQLを学んでPL言語等の存在を知ると基本的な考え方はすんなり判るようになった。
とは言え、「情報技術」的なアプローチの範囲は判るようになったが故に、さらに大きな壁が…。
やれプログラムとかデータベースとか、そういう情報技術の範疇でない、GISの知識に依存するあたりがさっぱり判らない…。

PostGISに位置データを突っ込むには、どういう座標系で解釈するかと言う事を指定するため、座標系を一意に指定するSRIDなる値を指定するみたいなんだけど、この値に何を指定すればいいのか判らない。
PostGISを入れれば1800種類くらいの測地系データが入ってくるんだけど、その中から目的の測地系を探す方法が不明。よく知られている測地系名略称であいまい検索をかけても一切出てこない。
しかも、検索できないなりにデータとして含まれているのならばまだいいんだけど、中村区アディクトさんあたりの情報を見ると、1800通りも入っていながら日本測地系も世界測地系も入っていない？
日本測地系は、中村区アディクトさんに教えてもらった限りでは、UTM座標系のデータはあるみたいなんだけど、単純な経緯度座標系のデータはないんだろうか…。

というか、そのUTM座標系とか、平面直角座標系とか自体、実は今回中村区アディクトさんの記事で始めて知った…なんで同じ測地系で座標系がいっぱいあるの？と最初のうちは大混乱。
とりあえず地図への投影時に使う座標系のようなので、個人的な利用用途(位置を持った情報をデータベースに叩きこんで、情報の位置をベースにした近隣検索を行ったり、情報間の距離計算や測地系変換をSQLベースで行ったり)にUTMや平面直角座標を使う事はなさそうなんだけど(地図への投影は「パクリ地図」を使ってきた関係上、独自のノウハウがあるので今のような使い方をする限り必要なし)、その単純利用をするためだけの日本測地・世界測地両座標系の基礎データがどこにあるか判らない…。
さっきの質問の続きで、さるがとんだらのたくぼさんと中村区アディクトさんのやり取りで

# sarugatondara 『横からすみません。
この辺は僕もあまりよくわかってないところなんですが、WGS84だとSRID=4326が使われる気がします。
あとEPSGで定義されている大元の情報はhttp://www.epsg.orgから入手できるようです。』
# nishioka 『すいません、WGS84はSRID=4326ですね。そもそもSRID=4030はPostGISに登録されてませんでした。orz...
勉強になります。』

昨日の「バク天!」で「大阪ノリ好き」の兄ちゃんがまたまた「大阪のノリの良さ」を調査してた。
道行くジャリに「かめはめ波」を打つ振りをしてどういうリアクションを返すかというやつ。
で、結果は期待通り。

それ見つつ、「この手の地域別の人間性調査を、全く同じ実験を東京でもやったり、他のところでもやったり、フィールドワークとして研究したらおもろいかもしれんなー」とか話してたら、その後の「ホムクル」の新コーナーで、全く同じ実験が始まった!
東京と大阪で、
・ファッションセンスのチェックしたり（結果：東京は高い品である事を自慢し、大阪は安く買えたのを自慢する）
・無料のティッシュを配って減り具合を調べたり（結果：東京は1時間おいてもなくならないが、大阪は10分でなくなる）
・見ず知らずの人が困っていたら助けるか調べたり（結果：1時間ほど実験して集まった額が、東京は200円程度、大阪は800円程度）
・子供に銃で打つネタを振ってリアクションするか調べたり（結果：東京の反応率4%、大阪の反応率70%）
という感じの実験を行ってたんだけど、まさに予測どおりというか期待通りというか、の結果で笑けた。
そういった特性の生まれた原因も、まあいわゆる「あるある」レベルの説明ではあるけれど、「武士による規範の町」東京と「町人による実利の町」大阪の成り立ちの違い、という事でうまく説明されていて、面白かった。

日本列島アンテナ’（奪取）の旅日記

アンテナ’参加者のふかちんさんが、応援サイトを作ってくださいました。

サーバ不調時(すみません)の避難所としても、という事で、感謝の限りです。

Posted with ecto

位置情報サイト&技術者なのに位置情報DBを使わない(使えない)のはいかがなものか、というのがあるので、ケータイ版DBあぼーんしたのをきっかけにPostGISの勉強を決めた。
というか、まだその前段階のPostgreSQLの勉強中。

その先鋭的な機能の多さにびっくり。
まあそれぞれ良い点悪い点はあるが、しかし機能の先進さ、という点から見たらMySQLがおもちゃに思える。
なかでも驚いたのがテーブル継承機能。
いろいろテストしてみて、機能自体は制約が多いため使えない(少なくともノウハウもなく、全て独学でメンターもいない私には)事が判ったものの、そういうのをDB側で実装しようと言う姿勢に脱帽です。
というか、本当に欲しいし、オブジェクト指向とか言ったってデータを永続化しようと思えば、RDBに写像するしか現実的な選択肢がない中で、他のDBでなんでこういう発想が出てこないかが不思議ではあるけど。

きのうkokoが、ここにnene2001がblogしなかったよ。
nene2001は、

HTML-Entities-Numbered[blogbulknewsnet]谷口にぽたん氏によるHTML実態参照と数値参照の相互変換モジュール。
どんなときに便利かって、RSSとかに&hearts;とか入ってると、XMLのパースエラーになってくれてパースエラーにならないですむ、というわけですな。
こちらの件の解決策という事ですね。
Postedwithecto

Visual C++ Toolkit 2003でCPANモジュールをmake [どんぞこ日誌]
Visual C++ Toolkit 2003メモ

Visual C++買わなくても無償でできるのか。
初めて知った。ちょっと感動。
これまでSpaceTag Serverがありながら、要件の判っている案件への適用ならばともかく、
やれBlogツールだのセマンティックWebだのの最新ネタの実験用としての、メインの開発環境をWindowsに移せなかったのはPurePerlでないPerlモジュールを(自分で)コンパイルできなかったせいなんだけど(1日何件何十件とCPANに登録される新モジュールの中で、気になるモジュールがあるたびに同僚にコンパイルを頼むわけにもいかないので)、
これなら完全にWindows＆SpaceTag Serverに移っちゃってもいいかもなあ。

というか、このToolkit、SpaceTag Serverに組み込めないのかな。
ライセンスは難しくって俺にはよく判らん。

Posted with ecto

HTML-Entities-Numbered [blog.bulknews.net]

谷口にぽたん氏による HTML 実態参照と数値参照の相互変換モジュール。
どんなときに便利かって、RSS とかに &hearts; とか入ってると、XML のパースエラーになっちゃうわけです。このモジュールの name2decimal とか name2hex を通すと、 &#9829; みたいになってくれてパースエラーにならないですむ、というわけですな。

こちらの件の解決策という事ですね。

Posted with ecto

Class::RDF [blog.bulknews.net]

Perl オブジェクトを RDF にマッピング。
というより、RDF で表現するデータを Class::DBI 経由でデータベースにマッピング、といったほうがいいのかな。

RDFのグラフ構造を直接取りこめるDBのツリー構造設計したら面白いかな、とか考えてたので、参考になりそうです。
おもしろそう。
というか、そんな要件ならRDB使わずにXMLDB使っとけって話もありそうですが。

Posted with ecto

なにかと書ける状況ではなかったので連絡が遅れましたが、月曜日にデータベースで操作ミスを行い、ケータイ版ここギコのデータが全て吹っ飛んでしまいました。
それ以来、ケータイ版ここギコに繋がらなくなっています。

一応、2大人気コンテンツだった携帯版Googleとアンテナ奪取のうち、携帯版Googleはデータベースとの連携がセッション処理程度だったため、1日程度で復旧しました。
アンテナ奪取については、1からの再スタートになりますが、以前のままの機能でとりあえず週明けには復旧したいと思っています。

kokoがnene2001とピピンしなかったー。
個別。

*このエントリは、こうさぎの「koko」が書きました。

Spidering hacks―ウェブ情報ラクラク取得テクニック101選でも紹介されている、天才的発想のHTML解析モジュールTemplate::Extractですが、実はビミョーに使えないっぽい…のが判明しました。
というのも、解析対象と解析テンプレートが、完全に同じであったり或いは完全に別物であったりすれば、すぐにきちんとマッチする(或いはしない)のですが、対象とテンプレートがビミョーに似てて、ましてやFOREACHやワイルドカード表現使ってたりすると、「マッチしない」と言う結果を出すのにフリーズしたのかと思うほど異常に時間がかかるのです。
これはまあ、おそらく正規表現でマッチさせてるので、似たような構造がたくさんあるといろんな分割を試してみてマッチの可能性を探りつづけるループに入ってしまうからなんだろうと思いますが、それにしてもこれではサイトがほんのちょっとのマイナーチェンジすれば途端に高負荷状態になってしまい、使えません。
Templateを逆展開して解析に用いる、という発想は天才的なんだけど…ちょっと使えなかった。

RSS Feed: ZOO

procfeedは直らないし、Feedrollは有料だし、困ったなー、と思ってたら、新しいRSS Feedサービスができていました。
いやー、すばらしい。感謝感謝。
さっそく、右サイドバーにGIS NEXTのRSS貼らせていただきました。

難点を言うならば、いろいろカスタマイズできるんですが、各エントリ頭の「<li>」を外せないのが多摩に瑕。

Posted with ecto

Yahoo Inc のローカルサーチ - Yahoo! Local ベータ NDO::Weblog

このYahoo! Localにしろ、Google Localにしろ、データはどこから取ってきてるんだろうか。
出てくる情報の整形度を考えると、WWWをクロールして得た情報とは思いにくいんだけど…電話帳なりの既存データベース＆個別契約クライアントの情報を使っているのかな。
だとすると、もちろん使えるサービスではあるんだけど、個人的にはイマイチ興味が薄れるなあ…。
私が随分前の考察に書いた検索結果にSense of wonderが感じられないという問題(問題と思わない人にとっては問題じゃないんだろうけど)は解決されないままで、その点ではMapionやMapFan等のサービスと対して変わらない気がする。

中学の頃まで爪を噛む癖があったのだが、なんでか15年近くも歳くった今頃になって癖が再発してしまった。
もう噛まないぞ、噛まないぞと思うのだが、気が付くと噛んでしまっている。
無意識の領域なのね。いったん出てしまうとなかなか直せない。
早く直さないと、爪がぼろぼろになってきてしまっているのだが。

Posted with ecto

今の住んでる新築の区民住宅。
家の設備とかは非常にいいのだけど、すごい問題があって、うちの棟だけで400人からの人、近辺の同時期に開いた区営/都営住宅も含めれば700人近い人がこの区画に住み始めたのに、近くにスーパー等が何もない。
歩いて4〓5分の最寄駅近くまで行くと、さすがに2店舗ほどスーパーは有るんだけど、駅に電車乗りに行くだけならたいした距離じゃなくても、1週間分の食材とか、ビニール袋ぶらさげて帰るには結構な労働になる。
ましてや、スーパーで何でも買ってると高すぎて家計が回らなくなるので、いわゆる「八百屋さん」や「肉屋さん」がある商店街に行こうと思うと、電車に乗って2つ隣の駅の商店街から10キロ以上の荷物持って…と言う状況。
学校に通いながらの子育ての苦労ともあいまって、毎日家内が悲鳴を挙げている。

えらい面白いサイト見つけました。
建設的な提案サイト 『新橋系』
仕事感のあたりとか非常に共感する。
(といってもアレだな。挙げてる実績とか比べもんにならなさそう。この本もそうだけど、大体この手のはマジで優秀な奴が書いて、マジでヘタレな奴が癒し系として読むと言う還流ができてるな。)

その中に、戦争の防ぎ方というエントリがあったけど、これは同感で、結局戦争ってのは政治活動であり経済活動だから、それで儲かると思えば始まっちゃうんだよね。
実際には、特に時代が進んで社会の絡み合いが複雑化するにつれ、本当に最終的な損益で見れば儲かる戦争なんてあり得ないとは思うんだけど、やっぱ短絡的に儲かると勘違いしてしまう奴らはいるので始まってしまう。
それならば防ぐには、始まる前からどう算盤はじいても儲からない仕組みを構築しちゃうのが本質的で、それには先にも書いた社会の絡み合いを複雑化して、利害関係を計算不可能な状況にしちゃうのが一番かなと。

瞬！ワード RSS blog.bulknews.net

瞬！ワードの RSS がでてます。RSS 1.0 なのですが構造がアレゲでなかなかよし。

ものはこちらなんですが、思わず微笑んでしまいました。

Posted with ecto

きょうkokoはnene2001とここにピピンしたよ♪
きのうnene2001の、アプリケーションとか位置した。
きょうkokoが位置しなかった。
nene2001で、本がXMLしなかったよ。


*このエントリは、こうさぎの「koko」が書きました。

最近ちょっとXSLT絡みの昔買った本（実例でわかるXML&XSLTハンドブック、XSLT完全活用マニュアル）、あまり真面目にではなくつれづれにだが、読み返してみた。
もう3年も前の本だから、仕様も変わって来ているだろうし、まだ使える内容なのかはよく判らんけど。

技術的に優秀だ、概念的にすばらしいとかいう位置情報プラットフォームの存在が先に来るのではなくて、
おもしろい位置情報アプリケーションがあって、そのアプリケーションが実はこのプラットフォーム上で動いている、へー、さすが、なるほどね、というほうが、
技術的にも商売的にも格好いいよね。

Posted with ecto

株式会社メモシンク

位置情報繋がりで昔声をかけていただいていらい親交させていただいている友人の、起こした会社のサイトがリニューアルしていました。
最近も飲みにいきませんかとメールしたところ連絡がつかずどうしたのかなーと思ってたんですが、えらいいろんな事始めはったみたいで、順調そうなアレで安心しました。
位置情報に限らない事業展開になったみたいですね。

なんか「お世話になったサイト」って、うちへのリンクもあるんですが…。
いやもちろん嬉しいんですが、こんないろいろな面で問題ありなサイト、こっちが勝手に張る分はともかく、逆に張ると問題起きないかなと心配になったり。

Posted with ecto