話題のGoogle+ですが、早くもAPIが出てきています（PHP版）。とりあえずメモ。
Google+非公式API
投稿者：てらだ
2011年7月29日金曜日
2011年7月21日木曜日
自由に使える地図データ
地図といえば、GoogleMapですが、もっと自由に地図のデータを使いたい場合には「OpenStreetMap(OSMと略すらしいです)」というものが使えそうです。
http://openstreetmap.jp/
「こんな良いものがあるなら、是非Androidアプリとして実装してみたい」
と思い、早速調べてみました。
googleで「openstreetmap api」で検索すると、
「JA:Xapi - OpenStreetMap Wiki」なるサイトがヒットしました。早速、サイトを開くと、地図データの取得方法が載っていました。
GoogleMapのようにメッシュ状にデータを取得したい場合、以下のようにするようです。
http://www.informationfreeway.org/api/0.6/map?bbox=11.54,48.14,11.543,48.145
ブラウザのURL欄に上記URLを入力すると・・・
はいっ！XMLでデータが受信できるようです。（なんだかモーレツに遅いです）
XMLには緯度経度らしきデータなどがありますので、
このデータを使えば地図が書けそうです。
マッハでAndroidアプリを作ります。
はじめに、OSMからデータを取得します。取得できたデータがXMLなのでXMLパーサーを作らなくてはなりません。
次に、地図の絵を作ります。緯度経度を座標にマップして、いっぱい線を描いていきます。緯度経度のマッピングに頭を悩ませました。（拡大したり移動したり大変でした）
また、線の種類によって色を変えたり、太さを変えたりしました。（高速道路は水色で太くなど・・・）
メッシュ画像ができたら、画面に並べていくと・・・
おぉぉぉ！地図が書けた。
ここまで来たら後はスクロール処理を実装すれば完成です。
以上、作った地図表示アプリをキャプチャーしました。
具体的な実装については、またの機会に投稿したいと思います。
投稿者：島田
http://openstreetmap.jp/
「こんな良いものがあるなら、是非Androidアプリとして実装してみたい」
と思い、早速調べてみました。
googleで「openstreetmap api」で検索すると、
「JA:Xapi - OpenStreetMap Wiki」なるサイトがヒットしました。早速、サイトを開くと、地図データの取得方法が載っていました。
GoogleMapのようにメッシュ状にデータを取得したい場合、以下のようにするようです。
http://www.informationfreeway.org/api/0.6/map?bbox=11.54,48.14,11.543,48.145
ブラウザのURL欄に上記URLを入力すると・・・
はいっ！XMLでデータが受信できるようです。（なんだかモーレツに遅いです）
XMLには緯度経度らしきデータなどがありますので、
このデータを使えば地図が書けそうです。
マッハでAndroidアプリを作ります。
はじめに、OSMからデータを取得します。取得できたデータがXMLなのでXMLパーサーを作らなくてはなりません。
次に、地図の絵を作ります。緯度経度を座標にマップして、いっぱい線を描いていきます。緯度経度のマッピングに頭を悩ませました。（拡大したり移動したり大変でした）
また、線の種類によって色を変えたり、太さを変えたりしました。（高速道路は水色で太くなど・・・）
メッシュ画像ができたら、画面に並べていくと・・・
おぉぉぉ！地図が書けた。
ここまで来たら後はスクロール処理を実装すれば完成です。
以上、作った地図表示アプリをキャプチャーしました。
具体的な実装については、またの機会に投稿したいと思います。
投稿者：島田
2011年7月20日水曜日
Mercurial + Bitbucket でいつでも幸せ（いつでも地獄、とも言う）。
みなさんこんにちは。
震災の影響もあって、開発リソースの一極集中によるリスクの軽減に関心が高まっています。
多少の災害程度で開発に支障をきたすようでは、21世紀の開発者の名が廃るとも言われ、
「どこにいても、何が起こっても開発を止めない」ため、分散・クラウド・モバイル環境下でのソフト開発もあたりまえ（？）な時代になってきました。
私も、移動中の電車やカフェ、自宅等での開発作業をすることが多くなりました。
その場合に問題になるのが、開発用サーバ、特にソースコードリポジトリへのアクセスです。
会社のオフィスでは定番の Subversion を使っていますが、オフィスの外からはアクセスできないようにしてあります。
したがって、外出先で差分を見たり、コミットして安心？したりすることができないという問題がありました。
その暫定対策として、これまでは、開発中のリポジトリ一式をコピーして持ち出し、ノートPC等の「ローカル」環境では、Mercurial を使って一時的にバージョン管理をしていました。
しかしこの管理はあくまでもローカルなので、常にオンラインで同期できているリポジトリよりは、やはり使い勝手の面で劣ります。
また、サーバにコミットすることによる「バックアップ」効果も得られないので、PCがクラッシュした場合も心配です。
そこで、以前から気になっていた Bitbucket を使ってみることにしました。
Bitbucketは、５ユーザまでなら無料・容量無制限（！）で使うことができる Mercurialベースの 開発リポジトリサービス(free code hosting)です。
（こんなものまで無料で使えるようになるとは、いい時代になったものです。）５人以上ならば人数によって段階的に課金されますが、
人数無制限となる最高課金レベルでも月額80ドルなので、自力でこれだけのサーバを維持することを考えるとかなり魅力的な価格設定です。
Bitbucketは、パブリックはもちろん、プライベートのリポジトリも作成できますし、WikiやIssue Trackingシステムも一緒に使うことができるので、小規模チームで分散開発するには十分な機能を持っているといえるでしょう。
オンラインで一瞬でサインアップも完了するので、Mercurialに慣れている人ならすぐにでも使い始めることができると思います。
（Mercurialを知らない人も、Subversionを既に知っていれば学習は容易だと思います。）
とりあえず、現状は、自分の作業ブランチを社内SVNから取得して、それを Bitbucketに上げて日々の作業しています。
（日々のコード差分は Bitbucket側にコミット）。
そして、ひととおり開発の区切りが付いたところで社内SVN側にもコミットする形としています。
これで社内・社外を問わず、連続的に開発作業を継続できるようになったので、とても快適です。
今後は、Mercurial側のSubversion連携機能を活かして、より有機的にリポジトリを扱えるようにしてみたいと思います。
投稿者：てらだ
震災の影響もあって、開発リソースの一極集中によるリスクの軽減に関心が高まっています。
多少の災害程度で開発に支障をきたすようでは、21世紀の開発者の名が廃るとも言われ、
「どこにいても、何が起こっても開発を止めない」ため、分散・クラウド・モバイル環境下でのソフト開発もあたりまえ（？）な時代になってきました。
私も、移動中の電車やカフェ、自宅等での開発作業をすることが多くなりました。
その場合に問題になるのが、開発用サーバ、特にソースコードリポジトリへのアクセスです。
会社のオフィスでは定番の Subversion を使っていますが、オフィスの外からはアクセスできないようにしてあります。
したがって、外出先で差分を見たり、コミットして安心？したりすることができないという問題がありました。
その暫定対策として、これまでは、開発中のリポジトリ一式をコピーして持ち出し、ノートPC等の「ローカル」環境では、Mercurial を使って一時的にバージョン管理をしていました。しかしこの管理はあくまでもローカルなので、常にオンラインで同期できているリポジトリよりは、やはり使い勝手の面で劣ります。
また、サーバにコミットすることによる「バックアップ」効果も得られないので、PCがクラッシュした場合も心配です。
そこで、以前から気になっていた Bitbucket を使ってみることにしました。
（こんなものまで無料で使えるようになるとは、いい時代になったものです。）５人以上ならば人数によって段階的に課金されますが、
人数無制限となる最高課金レベルでも月額80ドルなので、自力でこれだけのサーバを維持することを考えるとかなり魅力的な価格設定です。
Bitbucketは、パブリックはもちろん、プライベートのリポジトリも作成できますし、WikiやIssue Trackingシステムも一緒に使うことができるので、小規模チームで分散開発するには十分な機能を持っているといえるでしょう。
オンラインで一瞬でサインアップも完了するので、Mercurialに慣れている人ならすぐにでも使い始めることができると思います。
（Mercurialを知らない人も、Subversionを既に知っていれば学習は容易だと思います。）
とりあえず、現状は、自分の作業ブランチを社内SVNから取得して、それを Bitbucketに上げて日々の作業しています。
（日々のコード差分は Bitbucket側にコミット）。
そして、ひととおり開発の区切りが付いたところで社内SVN側にもコミットする形としています。
これで社内・社外を問わず、連続的に開発作業を継続できるようになったので、とても快適です。
今後は、Mercurial側のSubversion連携機能を活かして、より有機的にリポジトリを扱えるようにしてみたいと思います。
投稿者：てらだ
登録:
投稿 (Atom)