自作の逆ジオコーディングサービスをgoogle様にホスティングしていただいていて、それをjavaでもって実装していた。
ちょっと考えがあって実装してみたら実に秒からミリ秒単位への高速化を実現。
最初からやっとけよ!っていう内容なんですけどね。
無料枠と有料枠の端境でDataStoreとInstanceのバランスをとることもうまくいけそうだなあ、なんて年末にホクホク。
で、デプロイしたらとたんに文字化け。12/31早朝に。
データもソースも全部UTF8で固めてあっても。
イヤになるねぇ。Latin1圏がうらやましい。
結論はString.split()。
こいつのソース読んでないけど、これを行うと文字化けする。
やっぱ他人が作ったライブラリはわかんないね。
オブジェクト原理主義者の犯行だな!
ていうかいいよ別にバイト列で・・・
オブジェクト指向だ!!!!!!!とか、肩に力入りすぎ。この言語。
2013年12月31日火曜日
HttpURLConnectionが親切すぎて生きるのがつらい
誰なんですかねえ、こんなオレオレライブラリっぽいのマージしたのは。
自分のアプリだけで使っとけよ!というくらい親切すぎて生きるのがつらい。
getResponceCode()だけでブロックする、というよりread()でブロックする。
ブロックそのものは文句はないんだけど、せめてデータが1バイトでも届いているかチェックするためにinputstreamを取得するだけでブロックする。そこまで面倒を見て下さるなんて感激。
setReadTimeoutが、レスポンスが返ってくるまでの間という大くくりにしか適用できない。
サーバのレスポンスが一定以上だとそもそもreadできない。例外がおきる。
オレオレライブラリの作者には200以外いらなかったのはわかるが、よりによってFileがないよ、っていう例外放り投げるなんてたまげたなあ。超イケテル。
そもそも使うなという評価しか思い浮かばない。
確かにイチからhttpのような原始的なプロトコルの実装を今更やんのかよ、と言いたくなる気持ちもよくわかるけど、こういうオレオレライブラリはSDKから外したほうがいい。
シャリンノサイセイサンガーとかいう人は良く考えたほうがいい。
車輪は回るから車輪であって回らないのは車輪ではない。
無理に回す必要はない。よく回る車輪を作ればいい。
まあ、いろいろ多環境下における仮想環境がらみとかネットに強いアピールが必要だった当時の政治的背景とかあるんでしょうけど。
でもcommitした人に聞いてみたいね。
どう思う?って。
最初からselect()導入しとけばいいのに・・・
当時はなかったとしても、せめてThread.interrupt()できれば使い勝手は向上するとは思うけど、
いったい、だれがこんなもんSDKに忍ばせたんだろう
裏のスレッドでdisconnect()すればキャンセルできるよ!とかへぼすぎでしょ。。。
かくして車輪の再生産が始まるのであった。
自分のアプリだけで使っとけよ!というくらい親切すぎて生きるのがつらい。
getResponceCode()だけでブロックする、というよりread()でブロックする。
ブロックそのものは文句はないんだけど、せめてデータが1バイトでも届いているかチェックするためにinputstreamを取得するだけでブロックする。そこまで面倒を見て下さるなんて感激。
setReadTimeoutが、レスポンスが返ってくるまでの間という大くくりにしか適用できない。
サーバのレスポンスが一定以上だとそもそもreadできない。例外がおきる。
オレオレライブラリの作者には200以外いらなかったのはわかるが、よりによってFileがないよ、っていう例外放り投げるなんてたまげたなあ。超イケテル。
そもそも使うなという評価しか思い浮かばない。
確かにイチからhttpのような原始的なプロトコルの実装を今更やんのかよ、と言いたくなる気持ちもよくわかるけど、こういうオレオレライブラリはSDKから外したほうがいい。
シャリンノサイセイサンガーとかいう人は良く考えたほうがいい。
車輪は回るから車輪であって回らないのは車輪ではない。
無理に回す必要はない。よく回る車輪を作ればいい。
まあ、いろいろ多環境下における仮想環境がらみとかネットに強いアピールが必要だった当時の政治的背景とかあるんでしょうけど。
でもcommitした人に聞いてみたいね。
どう思う?って。
最初からselect()導入しとけばいいのに・・・
当時はなかったとしても、せめてThread.interrupt()できれば使い勝手は向上するとは思うけど、
いったい、だれがこんなもんSDKに忍ばせたんだろう
裏のスレッドでdisconnect()すればキャンセルできるよ!とかへぼすぎでしょ。。。
かくして車輪の再生産が始まるのであった。
2013年12月28日土曜日
android x86 4.2.2版をvmwareで起動する方法
rootでログインしてvmwgfx.koを削除するか新しいものを入手して置換するとよい
例によってlinuxのカーネルオブジェクトの配置はやたら深いところにあるので、find | xargsしてやるとよいと思う
例によってlinuxのカーネルオブジェクトの配置はやたら深いところにあるので、find | xargsしてやるとよいと思う
2013年12月17日火曜日
androidでのsqlite3管理には信じられないバグがある
android4.2.2.でのお話です。
androidでsqlite3を利用しているアプリをアンインストールすると、恐ろしいことにdatabasesディレクトリにroot以外触れないジャーナルが残されて、二度とそのフォルダが使えなくなる場合があります。
例えばadb shell上でlsをとってみると・・・
ディレクトリで、しかも000。
しかもなんだか知りませんが同名のファイルが2つもできてます。
二度と削除できないファイルの豪華同時二本立て。
器用ですねえ。
猛烈にfsckかけたくなりますね。
当然、この端末はrootをとっていないので自分でやっちゃったわけではありません。
システムがおおポカやからしてしまっているわけです。
恐ろしくて使えません・・・というわけにもいきませんので、どうにかしようと思った場合、一応、こんな状況でも、databasesディレクトリはユーザ権限でアクセスできます
mvは可能なので、これを消すために端末初期化とかrootをとるという選択肢は通常はユーザからゆるされることはないので、これでごまかすしかないでしょう。
やっぱり、発展途上のデバイスはコワイですねぇ
あんまり枯れてない上に、組み込み向けの開発だということを自覚しながら開発しないと。
androidでsqlite3を利用しているアプリをアンインストールすると、恐ろしいことにdatabasesディレクトリにroot以外触れないジャーナルが残されて、二度とそのフォルダが使えなくなる場合があります。
例えばadb shell上でlsをとってみると・・・
# ls -l databases ls -l databases d--------- root root 2013-12-17 10:52 sdb-journal d--------- root root 2013-12-17 10:52 sdb-journal #パーミッションを見ていただけますとわかる通り、全くでたらめです。
ディレクトリで、しかも000。
しかもなんだか知りませんが同名のファイルが2つもできてます。
二度と削除できないファイルの豪華同時二本立て。
器用ですねえ。
猛烈にfsckかけたくなりますね。
当然、この端末はrootをとっていないので自分でやっちゃったわけではありません。
システムがおおポカやからしてしまっているわけです。
恐ろしくて使えません・・・というわけにもいきませんので、どうにかしようと思った場合、一応、こんな状況でも、databasesディレクトリはユーザ権限でアクセスできます
ls -la drwxrwx--x u0_a46 u0_a46 2013-12-17 11:35 databases
mvは可能なので、これを消すために端末初期化とかrootをとるという選択肢は通常はユーザからゆるされることはないので、これでごまかすしかないでしょう。
やっぱり、発展途上のデバイスはコワイですねぇ
あんまり枯れてない上に、組み込み向けの開発だということを自覚しながら開発しないと。
2013年12月14日土曜日
Windows8.1標準機能のベアドライブバックアップ *追補の追補*
申し訳ございません。また書き忘れていたことを思い出しました。
Windows8.1ではwbadminでバックアップしたディスクをリストアすると、次回バックアップができなくなります。
はい。何を言っているのわかりませんでしょう。
わたくしにもわかりません。
※先月試した時点の話題です。個体差もあるかもしれませんし、現在は改善されているかもしれません。もはや検証する気は起きませんが。
わたくしの場合の状況は、上記のデカい文字で申し上げました通り、リストアは完了した段階で、もう一回バックアップを行おうとするときに
ディスク領域が不足しているため、保存場所にボリュームのシャドウ コピーを作成できません。バックアップするすべてのボリュームについて、シャドウ コピーの作成に必要な最小限のディスク領域が利用可能であることを確認してください。これは、バックアップの保存先と、バックアップに含まれるボリュームの両方について行う必要があります。
とか言われて失敗終了します。
1TBのディスクに対してカラッポの2TBのディスクをバックアップ先を指定しても、です。
要するにうそついてんだよMS。
もーやーだーなーこの会社。
めんどくせえから適当なこといって追っ払っちまえ、っていう態度アリアリ。
まあ、そうはいっても、バックアップができないのは納得がいきません。
このエラーが起きる前後でCAPI2のエラーが続発しているのがイベントログで確認できたので(暗号化サービスで、システム ライター オブジェクトで OnIdentity() の呼び出しを処理中にエラーが発生しました。)、それが原因かと思い、その対処策として提示されている対策を片っ端からとりましたが全く改善しませんでした。
コノ件については、だいぶ時間をかけて散々調べましたが原因が全く分かりませんでした。
数日後、あきらめて、たまたま更新されていたモジュールがあるらしいのでwindows updateかけて再起動したら再度バックアップができるようになりました。
理由は不明です。
デスクトップにxlsとかdocのファイルを置きまくっていた人しか喜ばない階層化できない(携帯のhome画面だって階層化できるのに!)スタート画面とか含めて
Windows8.1はOSではなくオモチャ
という結論に達しました。ハイ、ワタクシの無能は思いっきり棚の上に置き忘れています。
坊主憎けりゃナントヤラ。
でも、パッケージとしてWindows8.1を売ってるわけですからねぇ。
カーネルだけ優秀でも・・・ねぇ。
linuxがlinuxだけでは使い道がなくてUbuntuとかRedHatとか派生してくるのと同様の意味で、NTカーネル使ってるからイイっちゅー評価にはどうしても達しえませんでした。
おもちゃ大好きだから私はいいんですが、OSを求める人は購入すべきではありません。
Windows9をお待ちなさい。
悪いこと言わないから。
きっとよくなってますよ、may be
なんかあったかな他に・・・
さすがにうんざりしてこれ以降、あんまりwindowsさわってなかったから・・・
とかいって、また触り始めて全く懲りていないのです。
愉しいですねえトラブル。
脳汁ってんですか、そういうのが出ますね。
一歩間違えると、この年齢ですともうすぐ脳溢血に直結しそうですが。
Windows8.1ではwbadminでバックアップしたディスクをリストアすると、次回バックアップができなくなります。
はい。何を言っているのわかりませんでしょう。
わたくしにもわかりません。
※先月試した時点の話題です。個体差もあるかもしれませんし、現在は改善されているかもしれません。もはや検証する気は起きませんが。
わたくしの場合の状況は、上記のデカい文字で申し上げました通り、リストアは完了した段階で、もう一回バックアップを行おうとするときに
ディスク領域が不足しているため、保存場所にボリュームのシャドウ コピーを作成できません。バックアップするすべてのボリュームについて、シャドウ コピーの作成に必要な最小限のディスク領域が利用可能であることを確認してください。これは、バックアップの保存先と、バックアップに含まれるボリュームの両方について行う必要があります。
とか言われて失敗終了します。
1TBのディスクに対してカラッポの2TBのディスクをバックアップ先を指定しても、です。
要するにうそついてんだよMS。
もーやーだーなーこの会社。
めんどくせえから適当なこといって追っ払っちまえ、っていう態度アリアリ。
まあ、そうはいっても、バックアップができないのは納得がいきません。
このエラーが起きる前後でCAPI2のエラーが続発しているのがイベントログで確認できたので(暗号化サービスで、システム ライター オブジェクトで OnIdentity() の呼び出しを処理中にエラーが発生しました。)、それが原因かと思い、その対処策として提示されている対策を片っ端からとりましたが全く改善しませんでした。
コノ件については、だいぶ時間をかけて散々調べましたが原因が全く分かりませんでした。
数日後、あきらめて、たまたま更新されていたモジュールがあるらしいのでwindows updateかけて再起動したら再度バックアップができるようになりました。
理由は不明です。
デスクトップにxlsとかdocのファイルを置きまくっていた人しか喜ばない階層化できない(携帯のhome画面だって階層化できるのに!)スタート画面とか含めて
Windows8.1はOSではなくオモチャ
という結論に達しました。ハイ、ワタクシの無能は思いっきり棚の上に置き忘れています。
坊主憎けりゃナントヤラ。
でも、パッケージとしてWindows8.1を売ってるわけですからねぇ。
カーネルだけ優秀でも・・・ねぇ。
linuxがlinuxだけでは使い道がなくてUbuntuとかRedHatとか派生してくるのと同様の意味で、NTカーネル使ってるからイイっちゅー評価にはどうしても達しえませんでした。
おもちゃ大好きだから私はいいんですが、OSを求める人は購入すべきではありません。
Windows9をお待ちなさい。
悪いこと言わないから。
きっとよくなってますよ、may be
なんかあったかな他に・・・
さすがにうんざりしてこれ以降、あんまりwindowsさわってなかったから・・・
とかいって、また触り始めて全く懲りていないのです。
愉しいですねえトラブル。
脳汁ってんですか、そういうのが出ますね。
一歩間違えると、この年齢ですともうすぐ脳溢血に直結しそうですが。
android端末がsuspendに入らない
界隈じゃdeep sleepとかいうみたいですね。
なんでもいいんですけど。
携帯界隈は用語が特殊で戸惑いますね。ROMとかRAMとか。意味不明。横文字つかっといてさらにわざと誤用とか器用すぎてウラシマには生きるのがつらい。
サービスの起床の是非やスリープするタイミングを調べて、WakeLockが必要なのかどうか検証するため、xperiaでもってTICK_TIMEを受信した時刻をひたすらメモリ上に記録するサービスを作成し、それをbindServiceで任意のタイミングでのぞくアプリを作成してみました(ストレージを使用することによってOSがsuspendを抑止したらいやだから)。
見事に起きてる。ばっちり。
ディスプレイ消灯中がスリープ、という状態なんでしょうが、TICK_TIMEが最大でも数十秒ずれるだけでおおよそ平均1分間隔で受信できてしまっている。
画面点灯中は100ms以内にTIME_TICKが飛んでくるから確かに精度は落ちている。しかし・・・
ただクロック数落としてるだけでしょ、これ。
これ、スリープというより・・・ただの低電力モード?
アプリ自体は稼働してしまってるんだからsleepとはいえんよねぇ。少なくとも寝てない。
なんかほかのアプリがWakeLock離してないのかともおもったけど、「電池使用量」で調べてみてももっとも怪しいgoogle関連のサービスの総「スリープにしない」時間が1時間程度。
うーん、sonyのこの端末はカーネルレベルでsuspend抑止してる?
ホントかなあ?
「電池使用量」の表示欄も、こうなってみるとぁゃιぃね。
起動中、の欄も起動してないことになってるのに、事実こうやってTICK_TIMEを記録しつづけるサービスが動いているのだから(AlarmManagerのWAKEUPも使ってませんよ)。
電池の持ちはいいから、そこは別に文句はないのだけど、もしsuspendしないならWakeLockなんかいらん。
最近の他の端末ではするのだろうか。
位置情報サービスを切ってみたりWiFiを切ってみたりいろいろやってもなんだか寝ない。
もししないなら、もう過去の端末は切り捨ててしまってWakeLockはアプリレベルでは気にしなくていい????
でもそんなことないよなぁ、という気がするなぁ。
逆にKitKatではすぐ寝ちゃってたりするのかもしれない。
古いデバイスでも軽快に!というのが売りだから。
お金あればほかの実機も買って試験できるんだけどなぁ。
金が敵なのに、そのカタキに最近あわねぇんだよなぁ
なんでもいいんですけど。
携帯界隈は用語が特殊で戸惑いますね。ROMとかRAMとか。意味不明。横文字つかっといてさらにわざと誤用とか器用すぎてウラシマには生きるのがつらい。
サービスの起床の是非やスリープするタイミングを調べて、WakeLockが必要なのかどうか検証するため、xperiaでもってTICK_TIMEを受信した時刻をひたすらメモリ上に記録するサービスを作成し、それをbindServiceで任意のタイミングでのぞくアプリを作成してみました(ストレージを使用することによってOSがsuspendを抑止したらいやだから)。
見事に起きてる。ばっちり。
ディスプレイ消灯中がスリープ、という状態なんでしょうが、TICK_TIMEが最大でも数十秒ずれるだけでおおよそ平均1分間隔で受信できてしまっている。
画面点灯中は100ms以内にTIME_TICKが飛んでくるから確かに精度は落ちている。しかし・・・
ただクロック数落としてるだけでしょ、これ。
これ、スリープというより・・・ただの低電力モード?
アプリ自体は稼働してしまってるんだからsleepとはいえんよねぇ。少なくとも寝てない。
なんかほかのアプリがWakeLock離してないのかともおもったけど、「電池使用量」で調べてみてももっとも怪しいgoogle関連のサービスの総「スリープにしない」時間が1時間程度。
うーん、sonyのこの端末はカーネルレベルでsuspend抑止してる?
ホントかなあ?
「電池使用量」の表示欄も、こうなってみるとぁゃιぃね。
起動中、の欄も起動してないことになってるのに、事実こうやってTICK_TIMEを記録しつづけるサービスが動いているのだから(AlarmManagerのWAKEUPも使ってませんよ)。
電池の持ちはいいから、そこは別に文句はないのだけど、もしsuspendしないならWakeLockなんかいらん。
最近の他の端末ではするのだろうか。
位置情報サービスを切ってみたりWiFiを切ってみたりいろいろやってもなんだか寝ない。
もししないなら、もう過去の端末は切り捨ててしまってWakeLockはアプリレベルでは気にしなくていい????
でもそんなことないよなぁ、という気がするなぁ。
逆にKitKatではすぐ寝ちゃってたりするのかもしれない。
古いデバイスでも軽快に!というのが売りだから。
お金あればほかの実機も買って試験できるんだけどなぁ。
金が敵なのに、そのカタキに最近あわねぇんだよなぁ
結局googleに頼ってしまう
この間借りさせていただいているblogサービスもgoogle様のご支配下にありますが、以前google等に頼らず自力で逆ジオコーディング、ということを言っていましたが、結局google様のお慈悲にすがることにしました。
というのは、web apiを利用させていただくのではなく、(逆ジオコーディングにはGoogle Mapと併用しなければ利用できない規約があるためです)Google App Engine ちゅうのがあるってことを知ったからです。
ここは、まあいわばただのホスティングサービスなんですが、おもしろいのは無料であること(!!)、Tomcat(!!!)が利用可能であること。
すなわち、android用に作ったクラスがそのまんま移植作業なしで動いてしまうという点です。
最近まではpyとかだけだったらしいんですが、そこはウラシマですから存じ上げません。
(Cとsedとperlとshばっかりなので全く知りませんでした。 )
さらにすごいのは、httpsをしゃべってくれること(証明書付きで!)
オレオレ証明書ならいくらでも用意できますが、いちいち警告が出るのが(いくら経路を暗号化するだけの目的ですよ、と申し上げたところで )当然不審をそそりますし、だからといって経緯度情報は大切なプライバシですから経路上で暴露しながらパケットが到着しても困ります。
その点、お仕着せのhost名を使う限り信頼済みとなっているのがありがたいです。
市区町村レベルの情報を返すだけとはいえ、そこはインターネットですからその仮想パス上にはNFCとかKFCとかSDKとかAPIとか(あれ?話題のあそこなんだっけ)不思議な団体が目を光らせている可能性は排除しきれません。
受け取るのは携帯からのリクエストを想定している以上、経緯度とIPアドレスといった個人が特定できる情報ですからやはりある程度は神経質にならざるを得ません。
そりゃ証明書を買って自鯖でやったほうがいいに決まってます。
実際、このサービスは無料版の場合、処理速度はandroid実機で処理するのとどっこいどっこい。
DBも特殊。いついきなりサービスを終了するかもわからない。
電気代や回線代の分お得ですが、より柔軟なサーバ側のカスタマイズにも向きません。
でも結局お金がない。これにつきます。
これだけでキラキラ輝いて見えます。
しかもandroidとソースは一緒ですからどちらかメンテすれば自動的にもう一方に適用できるというすばらしさ。
修正モジュール、サーバ側はperl,端末はjavaで同様のロジックを・・・とかだったら鼻血が出ます。
携帯もドメイン管理もホスティングも検索もweb apiもblogも・・・ぜーんぶgoogle・・・
無料DDNSはもうやらないのかなぁ
最後の砦、携帯電話の番号だけはgoogle先生にお教えしておりませんが、携帯メアドはGoogle App Engineに登録する際に教えちゃいました。
どうでもいいけど送信者アドレス指定受信って日本で普及しているの知らないのかなgoogle大先生。日本ではxxx@yyy.zzzからメールが送られるから受信許可しといてねって一言ある商習慣をガン無視。
これがアベノミクスってやつかな。キッシンジャー外交かな?
意地でもMicrosoft accountを作らないアタクシとは思えないほどキモチワルイ状況です。
iOSとどっちだ!ってくらい。
Microsoftも仲間に入りたそうに見ているわけだわなぁ
というのは、web apiを利用させていただくのではなく、(逆ジオコーディングにはGoogle Mapと併用しなければ利用できない規約があるためです)Google App Engine ちゅうのがあるってことを知ったからです。
ここは、まあいわばただのホスティングサービスなんですが、おもしろいのは無料であること(!!)、Tomcat(!!!)が利用可能であること。
すなわち、android用に作ったクラスがそのまんま移植作業なしで動いてしまうという点です。
最近まではpyとかだけだったらしいんですが、そこはウラシマですから存じ上げません。
(Cとsedとperlとshばっかりなので全く知りませんでした。 )
さらにすごいのは、httpsをしゃべってくれること(証明書付きで!)
オレオレ証明書ならいくらでも用意できますが、いちいち警告が出るのが(いくら経路を暗号化するだけの目的ですよ、と申し上げたところで )当然不審をそそりますし、だからといって経緯度情報は大切なプライバシですから経路上で暴露しながらパケットが到着しても困ります。
その点、お仕着せのhost名を使う限り信頼済みとなっているのがありがたいです。
市区町村レベルの情報を返すだけとはいえ、そこはインターネットですからその仮想パス上にはNFCとかKFCとかSDKとかAPIとか(あれ?話題のあそこなんだっけ)不思議な団体が目を光らせている可能性は排除しきれません。
受け取るのは携帯からのリクエストを想定している以上、経緯度とIPアドレスといった個人が特定できる情報ですからやはりある程度は神経質にならざるを得ません。
そりゃ証明書を買って自鯖でやったほうがいいに決まってます。
実際、このサービスは無料版の場合、処理速度はandroid実機で処理するのとどっこいどっこい。
DBも特殊。いついきなりサービスを終了するかもわからない。
電気代や回線代の分お得ですが、より柔軟なサーバ側のカスタマイズにも向きません。
でも結局お金がない。これにつきます。
これだけでキラキラ輝いて見えます。
しかもandroidとソースは一緒ですからどちらかメンテすれば自動的にもう一方に適用できるというすばらしさ。
修正モジュール、サーバ側はperl,端末はjavaで同様のロジックを・・・とかだったら鼻血が出ます。
携帯もドメイン管理もホスティングも検索もweb apiもblogも・・・ぜーんぶgoogle・・・
無料DDNSはもうやらないのかなぁ
最後の砦、携帯電話の番号だけはgoogle先生にお教えしておりませんが、携帯メアドはGoogle App Engineに登録する際に教えちゃいました。
どうでもいいけど送信者アドレス指定受信って日本で普及しているの知らないのかなgoogle大先生。日本ではxxx@yyy.zzzからメールが送られるから受信許可しといてねって一言ある商習慣をガン無視。
これがアベノミクスってやつかな。キッシンジャー外交かな?
意地でもMicrosoft accountを作らないアタクシとは思えないほどキモチワルイ状況です。
iOSとどっちだ!ってくらい。
Microsoftも仲間に入りたそうに見ているわけだわなぁ
地図上に点を打って簡単なポリゴンを作りたい
表題のようなことをしたいなあ、という人はあまりいないかもしれませんが、ここに一人いたので実際にやってみました。
ポリゴンといってもそんな大げさなものではなくて、たとえば大雑把な地図上の地点をクリックしていって経緯度のリストができていれば、それは立派なポリゴンになるわけです。
で、特殊なソフトも入れたくないし、立派な地図も買うほどのものじゃない・・・というときにお役立ちなのが我が国の政府からは利用が制限されているgoogle mapさん。
なにが有用かというと、国内でいうと地図だけならゼンリンさんですが、google mapさん経由で閲覧する以上、プラスアルファがあるわけです。
Google Maps JavaScript API v3 (以下API)が利用できるため、地図とAPIを組み合わせるだけで、目的のものがいともたやすくできてしまいます。
政治上の信念や主張も大切ですが、ここはポリゴンのためです。政府職員でも何でもないわたくしはありがたく使わせていただきましょう。
で、APIなんか使わなくても、もともと特定地点の経緯度は特定の操作をすればすぐわかるようになっています。
ですが、その特定の操作が、連続して経緯度を得るにはちょっと根気がいる作業になってしまうという欠点があります。
そこで、真のプログラマたるもの、楽をしたいならどんな面倒なことでもやる。。。というほどのこともなく、この場合、面倒なことは一切ありません。
ちょっとブラウザ上で動くスクリプトを書けばいいだけで済んでしまいます。APIが整備されているおかげです。
しかも、このAPI、利用するためにgoogleさんに登録の必要がないというすさまじい太っ腹ぶり。シビれますね。
コードを書いたその瞬間からhttpをしゃべるサーバを立てることなく、ブラウザでローカルファイルとして作成したhtmlファイルを表示させてスクリプトを動かすだけで利用できてしまうという点でも助かります。
(「誰でも自由にアクセスできるウェブサイトであれば、無料で利用できるサービスです。」とありますが、さすがにコードを書いてる途中から公開できるわけがなく、ローカルで手軽にテストできるのがうれしいですね)
要点は非常に簡単。それこそその辺のサンプルを拾ってきて(本家のも含めて山ほどあります)、ともかくgoogle mapを表示するってな感じのスクリプトをまずhtmlファイルに追加します。
その時点でもう地図が画面上に表示できているはずです。
アトはもう簡単。クリックされたときに呼ばれるリスナを登録してあげるところだけがミソです。
たとえば
map = new google.maps.Map(document.getElementById("地図表示領域"), mapOptions);
としてmapオブジェクトを作ってあったとすれば、イベントリスナとして
google.maps.event.addListener(map, 'click', function(event) {
func(event.latLng );
});
のようにしてあげると(このjava記法ほんとダイキライ。javascriptトカjavaノトキケッキョクツカッチャウケド)、経緯度がfunc()に渡るのであとはどうでも好きにすればいいわけです。
※念のため、funcはAPIじゃないですよ、自分で定義した関数です。
どこをクリックしたのかわかりやすいようにマーカを表示させ、さらにリスナに渡されるオブジェクトのメンバに経緯度が入っているので、それをどこかに用意した要素(たとえばdiv部など)に
document.getElementById("point_list").innerHTML += location.lat() + "," + location.lng() + "<br/>"
のように追加していくだけで十分メタツールになりえます。
ポリゴンが完成したら、その要素からテキストをコピーすればいいわけです。
凝ろうと思えばいくらでも凝れる、一昔前ではまるで夢物語のような高性能アプリの雛形が、回線インフラと膨大な地図データとAPI(とインフレなPC性能)のおかげでたったの数十行でできてしまいます。
まさにネットウラシマを実感する瞬間です。
ポリゴンといってもそんな大げさなものではなくて、たとえば大雑把な地図上の地点をクリックしていって経緯度のリストができていれば、それは立派なポリゴンになるわけです。
で、特殊なソフトも入れたくないし、立派な地図も買うほどのものじゃない・・・というときにお役立ちなのが我が国の政府からは利用が制限されているgoogle mapさん。
なにが有用かというと、国内でいうと地図だけならゼンリンさんですが、google mapさん経由で閲覧する以上、プラスアルファがあるわけです。
Google Maps JavaScript API v3 (以下API)が利用できるため、地図とAPIを組み合わせるだけで、目的のものがいともたやすくできてしまいます。
政治上の信念や主張も大切ですが、ここはポリゴンのためです。政府職員でも何でもないわたくしはありがたく使わせていただきましょう。
で、APIなんか使わなくても、もともと特定地点の経緯度は特定の操作をすればすぐわかるようになっています。
ですが、その特定の操作が、連続して経緯度を得るにはちょっと根気がいる作業になってしまうという欠点があります。
そこで、真のプログラマたるもの、楽をしたいならどんな面倒なことでもやる。。。というほどのこともなく、この場合、面倒なことは一切ありません。
ちょっとブラウザ上で動くスクリプトを書けばいいだけで済んでしまいます。APIが整備されているおかげです。
しかも、このAPI、利用するためにgoogleさんに登録の必要がないというすさまじい太っ腹ぶり。シビれますね。
コードを書いたその瞬間からhttpをしゃべるサーバを立てることなく、ブラウザでローカルファイルとして作成したhtmlファイルを表示させてスクリプトを動かすだけで利用できてしまうという点でも助かります。
(「誰でも自由にアクセスできるウェブサイトであれば、無料で利用できるサービスです。」とありますが、さすがにコードを書いてる途中から公開できるわけがなく、ローカルで手軽にテストできるのがうれしいですね)
要点は非常に簡単。それこそその辺のサンプルを拾ってきて(本家のも含めて山ほどあります)、ともかくgoogle mapを表示するってな感じのスクリプトをまずhtmlファイルに追加します。
その時点でもう地図が画面上に表示できているはずです。
アトはもう簡単。クリックされたときに呼ばれるリスナを登録してあげるところだけがミソです。
たとえば
map = new google.maps.Map(document.getElementById("地図表示領域"), mapOptions);
としてmapオブジェクトを作ってあったとすれば、イベントリスナとして
google.maps.event.addListener(map, 'click', function(event) {
func(event.latLng );
});
のようにしてあげると(このjava記法ほんとダイキライ。javascriptトカjavaノトキケッキョクツカッチャウケド)、経緯度がfunc()に渡るのであとはどうでも好きにすればいいわけです。
※念のため、funcはAPIじゃないですよ、自分で定義した関数です。
どこをクリックしたのかわかりやすいようにマーカを表示させ、さらにリスナに渡されるオブジェクトのメンバに経緯度が入っているので、それをどこかに用意した要素(たとえばdiv部など)に
document.getElementById("point_list").innerHTML += location.lat() + "," + location.lng() + "<br/>"
のように追加していくだけで十分メタツールになりえます。
ポリゴンが完成したら、その要素からテキストをコピーすればいいわけです。
凝ろうと思えばいくらでも凝れる、一昔前ではまるで夢物語のような高性能アプリの雛形が、回線インフラと膨大な地図データとAPI(とインフレなPC性能)のおかげでたったの数十行でできてしまいます。
まさにネットウラシマを実感する瞬間です。
2013年12月13日金曜日
Windows8.1標準機能のベアドライブバックアップ *追補・重要*
たまたま、過去に書いたことを確認しているうちにとても重要なことを公開し忘れていることに気づきました。
過去、USBメモリではなくUSB接続のHDD(以下USBHDD)にバックアップからの回復用メディアを作ったほうが安心ですよ、と記述いたしましたが、これはMSに限っては嘘です。
USBHDDからシステムを回復しようとした場合、
USBHDDにある回復ドライブを消そうとしてリストアができません。
です。はい。
何を言っているかわからないと思います。
なお、HDDは
状況としては次のようになります。
ここがミソです。
文中にある通り、「現在回復環境を実行しているドライブ」とはUSBHDDのことです。
リストア先にはもはやカラッポのディスクがあるのですが、このスバラシイリストアソフトはUSBHDDの回復ドライブを消さないとだめだと強硬に言い張るのです。
もう、この会社にはSurfaceユーザと大企業ユーザ以外に相手をする気がないんだと思います。
この画面にたどり着くまでに、バックアップ先のHDDからバックアップデータを選択する必要があります。
ということは、カラッポのHDDが存在していることはシステムは知っています。
しかし、そこをリストア先に提案することはありません。
もちろん、バックアップ元はカラッポですからドライブレターが振られず、バックアップ先がCドライブとなってしまっていますから、そこはdiskpartコマンドできちんとZなどに振りなおしてみました。
しかし、やはりリストア先としてシステムは提案してくれません。
全くの憶測ですが、決め打ちで「回復ドライブから起動したらそこはリストア先」という、なんだか聞くだけで顔が恥ずかしくて真っ赤になるようなコードが書かれているのかもしれませんね。
もしくは、無料アップデートした旧Windows8ユーザに対する嫌がらせ・・・?さすがにうがちすぎでしょうか。
なるべくWindows8.1のライセンスごと買ってもらいたい、という思惑なのかもしれません。(メディアだけ購入なんて手段、一般ユーザにはありましたっけ?)
DVDから起動した場合のリストアの場合はこのようなメッセージは現われませんから、(もちろん、以前述べたように)Preview版ISOからのリストアは可能です。
(ただし、Preview版の有効期限が切れた後も回復メディアとして使用できるかどうかまでは、残念ながら検証できていません)
一般のユーザさんがPreview版のISOを焼いているかどうか、そこは疑問ですが・・・
やはりUSBフラッシュメモリを毎度リフレッシュし続けるか、Windows8.1を新規で買えってことで落ち着くのでしょう。
なぜ、リストア先ではない回復ドライブを消去する必要があるのかも不明ですし、カラッポになっているHDDもあるのに、そこへのリストアという選択肢も示さないのかも不明です。
しかし、マイクロソフトさまの製品を利用させていただく以上、偉大なご意志に従わなければなりません。
せっかく写真もとってあったのに、公開をしていなかったので、急いで追補とさせていただきます。
ほんとどうでもいいけど、そいやあ、なんか知らんがなんかおかね当たるようなキャンペーンやってるけど、これ当たっても、もらうには支払者情報の登録が必要なんだよね。
胡散臭いなあ。アメリカ人ってこういうの割と平気なのかな。facebookとか怖くて登録できない小心者にはキツイなぁ。appleやgoogleだってコワイのに実績がないMSのストアなんて・・・だから金券くばってんだろうけど。
過去、USBメモリではなくUSB接続のHDD(以下USBHDD)にバックアップからの回復用メディアを作ったほうが安心ですよ、と記述いたしましたが、これはMSに限っては嘘です。
USBHDDからシステムを回復しようとした場合、
USBHDDにある回復ドライブを消そうとしてリストアができません。
です。はい。
何を言っているかわからないと思います。
なお、HDDは
- バックアップ元のHDD
- バックアップ先のHDD
- 回復メディア用に作成するUSBで接続されたHDD
状況としては次のようになります。
- マイクロソフトさまの仰せのとおり回復ドライブを作成する(ただしUSBフラッシュではなくHDD)
- wbadmin、または「システムイメージの作成」でバックアップを取る
- バックアップ元を消す(ここでカラッポのHDDが1つできます)
- 1.で作成した回復ドライブからシステムを起動し、バックアップ先から(元のバックアップ元の)カラッポのHDDに、リストアをおこな、、、おうとする
ここがミソです。
文中にある通り、「現在回復環境を実行しているドライブ」とはUSBHDDのことです。
リストア先にはもはやカラッポのディスクがあるのですが、このスバラシイリストアソフトはUSBHDDの回復ドライブを消さないとだめだと強硬に言い張るのです。
もう、この会社にはSurfaceユーザと大企業ユーザ以外に相手をする気がないんだと思います。
この画面にたどり着くまでに、バックアップ先のHDDからバックアップデータを選択する必要があります。
ということは、カラッポのHDDが存在していることはシステムは知っています。
しかし、そこをリストア先に提案することはありません。
もちろん、バックアップ元はカラッポですからドライブレターが振られず、バックアップ先がCドライブとなってしまっていますから、そこはdiskpartコマンドできちんとZなどに振りなおしてみました。
しかし、やはりリストア先としてシステムは提案してくれません。
全くの憶測ですが、決め打ちで「回復ドライブから起動したらそこはリストア先」という、なんだか聞くだけで顔が恥ずかしくて真っ赤になるようなコードが書かれているのかもしれませんね。
もしくは、無料アップデートした旧Windows8ユーザに対する嫌がらせ・・・?さすがにうがちすぎでしょうか。
なるべくWindows8.1のライセンスごと買ってもらいたい、という思惑なのかもしれません。(メディアだけ購入なんて手段、一般ユーザにはありましたっけ?)
DVDから起動した場合のリストアの場合はこのようなメッセージは現われませんから、(もちろん、以前述べたように)Preview版ISOからのリストアは可能です。
(ただし、Preview版の有効期限が切れた後も回復メディアとして使用できるかどうかまでは、残念ながら検証できていません)
一般のユーザさんがPreview版のISOを焼いているかどうか、そこは疑問ですが・・・
やはりUSBフラッシュメモリを毎度リフレッシュし続けるか、Windows8.1を新規で買えってことで落ち着くのでしょう。
なぜ、リストア先ではない回復ドライブを消去する必要があるのかも不明ですし、カラッポになっているHDDもあるのに、そこへのリストアという選択肢も示さないのかも不明です。
しかし、マイクロソフトさまの製品を利用させていただく以上、偉大なご意志に従わなければなりません。
せっかく写真もとってあったのに、公開をしていなかったので、急いで追補とさせていただきます。
ほんとどうでもいいけど、そいやあ、なんか知らんがなんかおかね当たるようなキャンペーンやってるけど、これ当たっても、もらうには支払者情報の登録が必要なんだよね。
胡散臭いなあ。アメリカ人ってこういうの割と平気なのかな。facebookとか怖くて登録できない小心者にはキツイなぁ。appleやgoogleだってコワイのに実績がないMSのストアなんて・・・だから金券くばってんだろうけど。
2013年12月10日火曜日
経緯度から市区町村名を得たい
googleさんとかのオンラインサービスに頼らず自力で。
実際にやってみました。
国交省さんが公開している国土数値情報 行政区域データというのがおじゃる。
これ、よくできているなあ、と感心したのは、経緯度から市区町村名を得たい、という目的の場合、saxでも後方参照だけで面データに紐づいている市区町村名がわかるようにできていること。
あと、国土地理院みたいな半端なデータじゃなくてちゃんと水界とかも加味して"行政界として"ポリゴンが完結していること。
地味にありがたいよ、これ。
ご丁寧に始点と終点がreferenceになっていて間違いようがないように作ってある。そのreferenceも前方でまとめて定義してあるので、前方参照する手間がない。
実に助かる!
逆に言えば市区町村名から面を得ようとするとsaxでは前方参照が起こってしまうのですが。
saxにこだわるのは、パースしている状況をintな変数1つ+さっき見た要素の値だけで遷移させられるから。
確かに現在どういうことをやっているのかをしっかり管理しないといけないデメリットはありますが、メモリを大幅に節約できることはとても大きい。とくに組み込み機器向けには。
DOM作ったりxpath式で自由自在に取り出すのも結構だけど、それってちょっとリッチ杉。
日本の市区町村って2000近いもんねぇ。
というわけで、とにかく面白くてandroidでapk経由でデータを持ち込んでgoogle apiを使わないで市区町村名を得るアプリを書いてみたのですが・・・動くんだけど、元ネタファイルがデカすぎてapk形式ではもちづらいんですよねぇ。
assetsに格納してもeclipseさん激おこだし・・・
別個にダウンロードする形式にすれば・・・とか言い出すと、だったら最初から鯖/蔵でいいよねと。
いつ何時有料化されたり打ち切りになってしまうかわからないサービスを利用するのもコワイんで、ある程度自力でやりたいのですが、肝心の「ある程度」ってのをファイルサイズ的に痛烈に超過してしまっているので存在意義がないレベルまで落ちてしまう。
実際の処理としては本当に単純で、あらかじめ雑なふるい分けのために県単位での矩形を求めておけば47都道府県全部を検索する必要もなく、国外はそもそも検索する必要がない。処理時間としてはあっという間に終わってしまうCPUパワーを携帯ですら持ってる。
ただ結局市区町村を自力で特定するためには膨大なサイズのxmlをどうにかする必要があって、それをバイナリ化するなり自分で工夫する必要が出てきてしまう。
ここで急に一般化できなくなる。
国交省の作った最新ファイルで置き換えれば市町村合併にだってへっちゃら!なんてことができなくなっちゃう。
独自の変換用フィルタをかませるひつようがあるからねぇ。
結局現実的な対応としてはどっかからサーバと回線調達してきてユーザに必要な都度クエリを投げてもらう、というどっかで見たようなところに落ち着くんですかねぇ。
実は、どいつもこいつも時計の見た目やいい加減な予報(ほとんど曇りとかなんだよそれ。直訳すぎだろ。しかも台風来てても曇りだとか抜かすし)が気に入らないから、自分で時刻・天気予報(ちゃんと気象庁の)・スケジュール(ないけどね)をロックスクリーンに出すandroid向けwidgetを作っていて、できているんだけど、予報地域を手動で設定するより自動がかっこいいよね、と思って作ったらGISデータのほうがむちゃくちゃ大きくなって困ったなあ、ってだけなんですけどね。
実際に動いてはいるんだけど、これじゃ公開もできないよなぁ。
ま、需要はない気もするけど。
あればだれかがとっくに作ってるよね。
自己満足、自己満足。
実際にやってみました。
国交省さんが公開している国土数値情報 行政区域データというのがおじゃる。
これ、よくできているなあ、と感心したのは、経緯度から市区町村名を得たい、という目的の場合、saxでも後方参照だけで面データに紐づいている市区町村名がわかるようにできていること。
あと、国土地理院みたいな半端なデータじゃなくてちゃんと水界とかも加味して"行政界として"ポリゴンが完結していること。
地味にありがたいよ、これ。
ご丁寧に始点と終点がreferenceになっていて間違いようがないように作ってある。そのreferenceも前方でまとめて定義してあるので、前方参照する手間がない。
実に助かる!
逆に言えば市区町村名から面を得ようとするとsaxでは前方参照が起こってしまうのですが。
saxにこだわるのは、パースしている状況をintな変数1つ+さっき見た要素の値だけで遷移させられるから。
確かに現在どういうことをやっているのかをしっかり管理しないといけないデメリットはありますが、メモリを大幅に節約できることはとても大きい。とくに組み込み機器向けには。
DOM作ったりxpath式で自由自在に取り出すのも結構だけど、それってちょっとリッチ杉。
日本の市区町村って2000近いもんねぇ。
というわけで、とにかく面白くてandroidでapk経由でデータを持ち込んでgoogle apiを使わないで市区町村名を得るアプリを書いてみたのですが・・・動くんだけど、元ネタファイルがデカすぎてapk形式ではもちづらいんですよねぇ。
assetsに格納してもeclipseさん激おこだし・・・
別個にダウンロードする形式にすれば・・・とか言い出すと、だったら最初から鯖/蔵でいいよねと。
いつ何時有料化されたり打ち切りになってしまうかわからないサービスを利用するのもコワイんで、ある程度自力でやりたいのですが、肝心の「ある程度」ってのをファイルサイズ的に痛烈に超過してしまっているので存在意義がないレベルまで落ちてしまう。
実際の処理としては本当に単純で、あらかじめ雑なふるい分けのために県単位での矩形を求めておけば47都道府県全部を検索する必要もなく、国外はそもそも検索する必要がない。処理時間としてはあっという間に終わってしまうCPUパワーを携帯ですら持ってる。
ただ結局市区町村を自力で特定するためには膨大なサイズのxmlをどうにかする必要があって、それをバイナリ化するなり自分で工夫する必要が出てきてしまう。
ここで急に一般化できなくなる。
国交省の作った最新ファイルで置き換えれば市町村合併にだってへっちゃら!なんてことができなくなっちゃう。
独自の変換用フィルタをかませるひつようがあるからねぇ。
結局現実的な対応としてはどっかからサーバと回線調達してきてユーザに必要な都度クエリを投げてもらう、というどっかで見たようなところに落ち着くんですかねぇ。
実は、どいつもこいつも時計の見た目やいい加減な予報(ほとんど曇りとかなんだよそれ。直訳すぎだろ。しかも台風来てても曇りだとか抜かすし)が気に入らないから、自分で時刻・天気予報(ちゃんと気象庁の)・スケジュール(ないけどね)をロックスクリーンに出すandroid向けwidgetを作っていて、できているんだけど、予報地域を手動で設定するより自動がかっこいいよね、と思って作ったらGISデータのほうがむちゃくちゃ大きくなって困ったなあ、ってだけなんですけどね。
実際に動いてはいるんだけど、これじゃ公開もできないよなぁ。
ま、需要はない気もするけど。
あればだれかがとっくに作ってるよね。
自己満足、自己満足。
登録:
投稿 (Atom)