話題の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連携機能を活かして、より有機的にリポジトリを扱えるようにしてみたいと思います。
投稿者：てらだ
2011年7月13日水曜日
動けばいいってもんじゃない！（ソフトウェア設計の話）
こんにちは。
オブジェクト指向プログラミングの本質（の一つ）は、「クラスやメソッド等の言語要素を持ち込んで、コードを冗長にするコストを払ってでも、コードを読みやすくする」ことなのですが、このことをあまり理解せずに実装しているのを今だに良く見かけます。最近見かけた例を紹介しましょう。
この例では、「２つの異なるトリガーによって起動される処理Aをどう実装するか」がテーマです。
具体的には以下のような要件でした。
（１）トリガー１：タイマーがタイムアウト
（２）トリガー２：ユーザが終了ボタンをクリック
（３）処理A:ファイルを閉じてプログラムを終了する。
（４）シナリオ：トリガー１又はトリガー２が発生したら、処理Aを実行する。
これを某プログラマさん（外注さんです。すみません。）は下記のように実装していました。動作としてはバグはなく、一応要件を満たしてはいましたが、コードを見ると、動作シナリオが読み取りにくいものになっていました。（言語はJavaで、関係のない細かいところは省略しています。）どこが良くないか分かりますか？
私なら以下のようにコーディングしたいところです。
「これぐらい大した違いじゃない」と思われる方もいるかも知れません。しかし、大規模なプログラムになってきて、こうした問題があちこちに現れてくると、一気に解読コストが上がっていきます。「ちりも積れば・・・」のことわざ通りです。派生開発や保守・引き継ぎ等で非常に骨の折れるコードは、大抵こういった問題を抱えたものが多いのです。
読みやすいコードを書いておけば、拡張がしやすく、引き継ぎもしやすくなり、最終的には自分の身を助けることにつながります。設計力の向上にもつながるので常に意識しておきたい課題です。
投稿者：寺田
オブジェクト指向プログラミングの本質（の一つ）は、「クラスやメソッド等の言語要素を持ち込んで、コードを冗長にするコストを払ってでも、コードを読みやすくする」ことなのですが、このことをあまり理解せずに実装しているのを今だに良く見かけます。最近見かけた例を紹介しましょう。
この例では、「２つの異なるトリガーによって起動される処理Aをどう実装するか」がテーマです。
具体的には以下のような要件でした。
（１）トリガー１：タイマーがタイムアウト
（２）トリガー２：ユーザが終了ボタンをクリック
（３）処理A:ファイルを閉じてプログラムを終了する。
（４）シナリオ：トリガー１又はトリガー２が発生したら、処理Aを実行する。
これを某プログラマさん（外注さんです。すみません。）は下記のように実装していました。動作としてはバグはなく、一応要件を満たしてはいましたが、コードを見ると、動作シナリオが読み取りにくいものになっていました。（言語はJavaで、関係のない細かいところは省略しています。）どこが良くないか分かりますか？
// アプリメイン（よくない例）
class App implements TimeoutListener, OnClickListenr {
...
// タイムアウト時のコールバック
public void onTimeout() {
// 全てのファイルを閉じる
closeAllFiles() ;
// アプリを終了する。
exitApp() ;
}
// ボタンクリック時のコールバック
public void onClick( Button btn ) {
if( btn == this.btnCommandQuit ) { // 終了ボタンが押された・・
onTimeout() ;//XXX
}
}
}
答えは、//XXXというコメントをつけた行です。終了ボタンのクリックを検知したら、onTimeout()を呼び出していますよね？ このソースを普通に読み下すと「終了ボタンがクリックされたら、タイムアウトコールバックを呼び出す」となりますが、意味的に要件と直結しないので、「どうしてこうなっているのだろう？」と読者を悩ませることになってしまいます。私なら以下のようにコーディングしたいところです。
// アプリメイン（改良版）
class App implements TimeoutListener, OnClickListenr {
...
// タイムアウト時のコールバック
public void onTimeout() {
// 処理Aを実行
procedureA();
}
// ボタンクリック時のコールバック
public void onClick( Button btn ) {
if( btn == this.btnCommandQuit ) { // 終了ボタンが押された・・
// 処理Aを実行
procedureA();
}
}
// 処理A
protected void procedureA() {
// 全てのファイルを閉じる
closeAllFiles() ;
// アプリを終了する。
exitApp() ;
}
}
上記のコードならば、要件を直接対応づけて、容易にコードを読むことができるはずです。「これぐらい大した違いじゃない」と思われる方もいるかも知れません。しかし、大規模なプログラムになってきて、こうした問題があちこちに現れてくると、一気に解読コストが上がっていきます。「ちりも積れば・・・」のことわざ通りです。派生開発や保守・引き継ぎ等で非常に骨の折れるコードは、大抵こういった問題を抱えたものが多いのです。
読みやすいコードを書いておけば、拡張がしやすく、引き継ぎもしやすくなり、最終的には自分の身を助けることにつながります。設計力の向上にもつながるので常に意識しておきたい課題です。
投稿者：寺田
登録:
投稿 (Atom)