ここギコ！: iPhone水平展開開発：Xcodeでコードと案件毎リソース／設定の分離
Xcodeでの開発で、バージョン管理システムを使っておられる方って、特にブランチばりばり切って開発されてる方とか、どうやって運用されているのでしょうか...。 AppName.xcodeprojディレクトリの下の、project.pbxprojファイルって、ブランチ間のマージが気が狂いそうになるほど大変じゃないですか？ 中を覗いてもどこで何が設定されているのか判らないし、適当にマージしてみれば、Xcodeで読み込んだ時に必要なリソースへのリンクがターゲットから外れてて不具合の原因になったりして、時々泣きそうになります。 1プロジェクト＝1案件であれば、まだ大変さもそこまでではないかもしれませんが、コードを共有する汎用アプリプロジェクトの中で、リソース等を変更した複数の水平展開アプリをターゲット設定する時とか、マジ死ねます。 trunkのコードをいったん凍結して、新規開発はbranch
ここギコ！: GPS高度、ジオイド高、標高の関係
GPSでの高度の扱いについて知るために、ちょっとGPSトラッキングを行って実験をしてみました。 より大きな地図で ジオイド調査 を表示 ▲ iPhoneのGPSトラッカーで取得したトラッキングデータ。 ▲ 赤は行きの林試の森付近データ、青は帰りのかむろ坂付近データ。 この区間を歩いた際の、GPSの高度データも当然残っているので、それをグラフ化してみました。 同時に、こちらのサイトから取得できる、トラッキングされた経緯度での標高のデータを取得し、一緒にグラフ化してみました。 ▲ 上が林試の森付近のGPS高度/標高プロファイル、下がかむろ坂付近のそれ。 ▲ 両者間に30mくらいの差がコンスタントに存在。 すると、GPS高度と標高のデータの間に、30mくらいの差があるのが判ります。 これは何なのでしょう？ GPSの取得誤差？標高のデータ取得元に、『算出される標高には最大で50m程度
ここギコ！: PostGISとPostgreSQL幾何データ型の比較
これだけで終わらせるのもあれなので、実際にPostGISとPostgreSQL幾何データ型の周辺検索の比較を行ってみた。 結果は...あれだけアジった結果としてはちょっと恥ずかしい？1勝1敗に終わった。 （とはいえ、元記事そのままのやり方ではそもそも比較の対象にすらできず、前エントリで私がフォローしたやり方とPostGISとの比較なので、ちょっと勘弁いただきたいといいたいところでもある） 何をもって1勝1敗というかについては、以下記事参照。 とりあえず、組み込みの幾何データ型とPostGISジオメトリ型のカラムを持つテーブル作成。 CREATE TABLE geodata (id serial, geo_pseudo point); SELECT AddGeometryColumn('geodata', 'geo_right', 4326, 'POINT', 2 ); こんな感じで、
ここギコ！: GoogleMapsと連動したいなら幾何データ型よりPostGIS
なんか向こうのコメントに書き込んだのだが、よく判らんが削除されてしまったのでこっちのエントリで取り上げる。 データベース上の位置情報を効率的に検索する方法(PostgreSQL編) -Web屋のネタ帳- たとえばおいしいケーキ屋さんの位置情報がデータベース上にあるとしよう。...GoogleMapsなどである範囲の地図を表示したとして、お店の位置を地図上にマーキングさせたい場合には、その地図の範囲の情報をキーにしてデータベース上の緯度経度を検索する必要がある。 ......... だが、ひとたび ある1点から半径rの円内に該当するデータを検索したい さらにその検索結果を、中心点からの距離でソートしたい といったことになると、とたんに難しくなる。しかし、PostgreSQLにもう5年以上前から実装されている幾何データ型、幾何関数、幾何演算子を使えば、SELECT一発でできることだ。 幾何
ここギコ！: 自分で産んだ全体最適化ソリューションに自分でトドメさした...合掌
Posted by nene2001 at 14:23 / Tag(Edit): 国盗り PSGI Apache / 0 Comments: Post / View / 0 TrackBack / Google Maps 元記事が見つけられないのだけど、昔ライブドアの誰だったかの記事を読んだことがあります。 記憶でその記事に書かれていたことを書くと、ライブドアでは全サービス共通の会員認証とか、そういう部分をライブラリ的に提供してアプリに組み込むのではなく、Apacheモジュールを作ってアプリより上層で処理しているそうです（ライブドアでそういう事実がないなら、すんません、どっか別の会社と間違えたのだと思います。でも、記憶では100%ライブドアなんだけど）。 理由は、アプリの開発は技術者個々人のもっとも使いよい言語（Perl、Ruby、etc...）で作ることを尊重しているの
ここギコ！: PostGISで1点からの半径検索は、UTMなりに変換してから検索するのがベストプラクティス？
2008年01月26日 PostGISで1点からの半径検索は、UTMなりに変換してから検索するのがベストプラクティス？ PostGISで半径x m内の地物を検索する場合、latlong（経緯度）で入っているデータだと空間インデックスが効かないので、どうするかと言う問題ですが。 以前、こんな記事を書いて、むりくりlatlong上で「半径x mの円」を内包する（内接ではない）矩形をざっくり計算し、それを空間インデックスと引き当てて、その後distance_sphere（latlongで入っているテーブルに対し、地球を球体近似した上での表面距離を算出する関数）の実行結果と比較する検索方法を紹介しました。 が、これは別にこれが常道というわけではなくて、GIS素人がちょっとずつ独学して、どんなやり方をすればいいかと試行錯誤した結果の産物です。 まあ言うなれば、ISSEIと同レベルのもの。 が、
ここギコ！: Visual Source Safe+Google Desktop Searchでもドキュメント管理
2005年06月01日 Visual Source Safe+Google Desktop Searchでもドキュメント管理 こちらで報告したSubversion＋GDSでドキュメント管理をするシステムの案ですが、社内レビューをしたところ、やはりWordやExcelといったバイナリファイルをバージョン管理するのに、SubversionやCVSといった衝突検知->マージ型のバージョン管理は難しいのでは、という検討結果になった。 Diffが効かないので、下手をすれば差分を抽出するのにかかる時間・手間のコストの方が、バージョン管理で得られるメリットに勝る場合があり得るからだ。 やはりバイナリドキュメントを管理するのならば、完全排他型の管理でなければ、という話になった。 一理ある。 で、またいろいろ大勢で検討していると代案も出てくるもんで、完全排他型のバージョン管理システムの代表であるVSS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
