Webサービス「避難施設マップ」を再開してみた

国土交通省が公開している国土数値情報のデータを利用して、だいぶ前にWebサービス「避難施設マップ」( https://hinan-map.info/ )を作ったけれど、出来上がってしまったら満足してしまい、その後は放置状態だった。9月1日防災の日が近づいてきて、そういえばあんなの作ったよなぁ、と思って久しぶりにアクセスしてみると、色々と不具合が出ていてまともに動作しない。調べてみると Google Maps の API 利用規定が変わったことなどが原因みたい。利用者はいないだろうと思いつつ、この機会にメンテナンスすることにした。

Screenshot_20160901-105006

実際に修正を試みたのは次の3点。ただし最後のひとつは実現できなかったのだが、そのことは後述。

Google Maps アクセス用のAPIキー設定

このサービスの公開時、Google Maps を利用する際にAPIキーの設定は任意だった。ところが2016年6月から、このAPIキー設定が必須となった模様。そのため地図表示がまったく出来ない状態になっていた。そこで Google API コンソールから新たにAPIキーを取得し、コードに埋め込んだら再び地図を表示するようになった。

現在の Google API は、利用サービスがかなり細かく分類されていて、必要なサービスを事前に有効化指定する必要がある。今回は地図表示用の API として Google Maps JavaScript API を使ったのだが、この API だけでは2点間のルート表示をすることが出来ず、さらに Google Maps Directions API も有効にする必要があった。これによって避難施設マップにおける現在地から避難施設への経路表示も復活できた。

SSLを導入してHTTPSに対応

避難施設マップでは現在地を表示する機能があり、HTML5 の Geolocation API を利用している。サービス開始当初は問題なく現在地を取得していたのだが、なぜか現在地の取得が必ず失敗するようになっていた。調べてみた結果、Chrome ブラウザのバージョンが 50 以降の場合、セキュリティ強化目的で http 接続での Geolocation API が廃止されているとのこと。

参考にした記事(@IT:「Chromeブラウザで現在地情報を正しく取得できない場合の原因と対策」)によると、仕様変更したブラウザはいまのところ少数派のようだが、他のブラウザもいずれはこのような対応が予想されるので、ここは素直にサーバ証明書を導入して避難施設マップサービスへのアクセスを完全に https 化した。サーバ証明書は無料で利用できる StartSSL から入手した。ここのサーバ証明書は簡単に入手できるので、開発用途などに重宝している。

避難施設データの更新

このような修正作業をしたついでに肝心の避難施設の元データも最新のものに更新したいと思った。避難施設マップで使っている国土交通省の国土数値情報データは平成24年度(2012年度)のものだったので、さすがに更新されているだろうと思ったのだが、国交省のWebサイトには依然として同じ年度のデータが公開されていた。来年度はこのデータ公開からちょうど5年目になるので、もしかしたら更新されるかもしれない。しばらくは国交省サイトのウォッチを続けようと思う。

 

避難施設マップは、すでにスマートホンのアプリとして多くのものが利用可能だったり、あるいは多くの自治体がそれぞれの地域限定で避難施設の情報をWebページで公開してもいるので、いまさら自前で避難施設マップを公開しても意味ないかとも思ったが、まあこういったものがたくさんあれば、万一のときのバックアップ程度にはなるかもしれないので、この後もしばらくは公開しておくことにする。この避難施設マップは北海道から沖縄までの全都道府県のデータを古いながらも網羅しているので、土地勘の無い場所で避難施設を探さなければならないような事態に遭遇したときなどは、多少お役に立てるかもしれない。

 

Webサービス名:避難施設マップ
利用方法:スマートホン、タブレット、PC等のWebブラウザで利用可能
URL: https://hinan-map.info/

Nexus7 2013 LTE 版 Lollipop アップデート時のトラブル

なぜか Nexus7 2013 LTE 版だけ放置されていた Lollipop がようやく正式公開されたので、手元の端末をさっそくアップデートしたら、いきなり 4G 通信が出来ない状態に。検索するとあちらこちらで同様のことが起こっているようだ。自分の端末では設定メニューから「モバイルネットワーク設定」 → 「通信事業者」に行って、明示的に事業者名を再設定することで、4G 通信が使えるようになった。ただ、その後もう一度事業者一覧を表示しようとしたところ、なぜか検索中のままになってしまい一覧を表示することが出来なかった。それでもいまのところ一応 4G 経由の接続は出来ている模様。

Chromebook を手に入れた

以前から気になっていた Chromebook をついに購入してしまった。国内では法人向けの販売に続いて個人向けの販売も始まっている。購入にあたって英字配列キーボードを必須としたが、現時点で英字配列キーボードを搭載している機種は ASUS C300MA(カラーバージョン) しかなく、しかもこれらはメモリが2GBしかない。他の機種が概ね4GBになっている状況で2GBでは先々がちょっと不安。というわけで国内正規版の入手を諦め、amazon.com 経由で東芝製の CB35-B3340 というモデルを購入した。本体価格は$279で送料その他諸々含めて、合計$327.45。実際に日本円で支払ったのは40,039円だった。同程度のスペックの国内正規品が概ね3万円台後半の値付けになっていることを考えると、この価格は悪くない買い物だったと思う。

20141220_124840

TOSHIBA CB35-B3340 (購入機種) ASUS C300-MA (参考)
CPU Celeron N2840 2.16GHz Celeron N2830 2.16GHz
メモリ 4GB DDR3 1600MHz 4GB DDR3 1333MHz
ディスプレイ 13.1 inches 1,920 x 1,080 13.1 inched 1,366 x 768
外部記憶域 16GB eMMC 16GB eMMC
バッテリ駆動時間 約9時間 約10時間
重量 約1.3Kg 約1.4Kg
価格 40,039円(送料等込) 39,744円(amazon.co.jp)

IMG_20141220_125154

筐体については値段相応で plasticky 感が強いのだが、そのことが逆に気楽に使える道具の印象となっていて個人的には嫌いではない。PC としての使い勝手については、ほかのブログなどでも書かれているように、良くも悪くも Chrome ブラウザしか動作しないノートPCということに尽きる。従って普段から Google 提供の各種サービスを使っているユーザでないと Chromebook を持つ意味はないかもしれない。しかし、GmailやGoogleカレンダーだけでなく文書作成からプログラミング作業の一部までを Chrome ブラウザ環境でまかなっている状況では、有用なモバイルツールになる。実際、自分の場合もメールはもちろん、ドキュメント作成のかなりの部分を Google に依存しており、加えてシステム開発の一部もブラウザ経由で作業しているため、起動が早くてバッテリの持ちも良い Chromebook は重宝している。

Chrome の不具合

10日ほど前からだったか、Windows7 64bit 環境でChromeが変な動きをするようになった。まず、Chrome上で文字入力するとき、文字の表示やバックスペースが極端に遅くなる。また、マウスクリックやホイールの動きに画面が追いつけないような状態になる。これらの現象が特にGmailとGoogle Driveまわりで顕著だった。

当初はChromeの拡張機能に原因があるのかと思い、キーボードやマウスの入力に絡みそうな拡張機能を無効にするなどしてみたが解決出来なかった。とにかく文字入力の効率が極端に落ちるためストレスが溜まる一方で、常用ブラウザをFirefoxへ変えないとならないかなぁと、ここ数日は落ち込み気味だった。

それでも暇を見つけては情報収集していたら、Googleプロダクトフォーラムで解決策にたどり着くことができた。原因はグラフィックドライバだった。手元の環境のディスプレイアダプタはAMD Radeon HD5750で、このドライバを最新のものにしたら、見事に問題が解消した。

https://productforums.google.com/forum/#!topic/gmail-ja/N8F0o2t08ig
https://productforums.google.com/forum/#!category-topic/chrome-ja/6x3uRPTmUtE

最新版のドライバは次のところで入手可能。

http://support.amd.com/ja-jp

AMDのサポートサイトには、既存ドライバ関連ファイルを削除してから新しいのをインストールするように、みたいな記述があったのだが、そういった事前準備することなくダウンロードしたインストーラをすぐに実行したところ、いまのところ問題なく動作している模様。Chromeの状態もトラブル発生以前のように快適に動作している。

パソコン自作していた頃は、グラフィックドライバなどのバージョンアップ情報はいつもフォローしていて、最新版が出たら速攻でバージョンアップして悦に入っていたけれど、最近ではもうそのあたりは完全にほったらかし状態で、今回の件ではドライバのバージョンがすごく上がっていたことや、ATIブランドがいつのまにか完全にAMDになっていたことなんかも、全然知らなかった。

「納品をなくせばうまくいく」を読む

ソニックガーデン社の倉貫さんが「納品しない受託開発」を実践していることは、ネットの情報や知人から見聞きしていた。このように書籍としてまとまったものを読んでみて、「納品しない受託開発」は自分が理想としてきた働き方を実現できる方法に違いないという思いを改めて確認した。いかに多くの予算を獲得し、手離れの良いやり方で納品して売上を回収したら次の案件へ、という従来のやり方ではなく、顧客のパートナーとして、そのビジネスに共感しビジネスの成長に必要なソフトウェアを長期的・継続的に提供する、という「納品しない受託開発」の方法論は、ソフトウェアの開発工程としても無理が無くとても自然体に見える。

考えてみると個人事業としてひとりで開発業務を始めた十数年前の頃は、1件あたりの開発期間が比較的長期に渡るものが多く、期せずして「納品しない受託開発」的な状況が、わずかながらも見え隠れしていたような気がする。しかし、その後は案件の短納期・低価格化が急激に進んで、顧客とビジネス感を共有するよりも、いかに良い条件で受註し短期間で仕上げて案件の数を稼ぐか、ということばかりに目がいってしまい、いつのまにか自ら窮屈な働き方を選択するようになってしまったように思う。そのことを本書が気付かせてくれた。

そこでさっそく自分も「納品しない受託開発」を実践したいところだが、ひとりきりの個人事業という現在の状況で本当に「納品しない受託開発」をできるかどうかは不安なところでもある。本書でも述べられているように、「納品しない受託開発」では基本的にひとりの技術者が顧客に対応するものの、その技術者が所属するソニックガーデン社が組織としてバックアップする。これは顧客から見れば、ひとりきりの個人事業者と取引するよりも遥かに安心できる担保となる。このことは「納品しない受託開発」かどうか以前に、ひとりきりの個人事業の場合にはいつでもついてまわる頭の痛い問題である。自分の場合は、同じような形態で働いている仲間との連携を常に意識しているものの、やはりひとりきりの個人事業では限界があると言わざるを得ない。ここはソニックガーデン社が行っている「ギルド」に参加するのが早道なのだろうか。

ところで、本書はソフトウェア開発という限定された世界に限らず、どのような仕事にもあてはまるであろう素敵な一文があちらこちらに散りばめられている。その中から幾つかを抜粋してみた。

顧客にとっては、ソフトウェアは完成させるだけでは意味がありません。それ以降にどれだけソフトウェアを「使う」ことができるのか、に意味があります。

「納品のない受託開発」ではソフトウェアの完成がゴールではありません。重要なのは、顧客のビジネスを成長・発展させることです。

私たちは、仕事は一生のものだと考えています。自分たちが大切だと思う仕事をずっとやっていきたいし、それはマラソンのようなもので、短距離走ではありません。ですから、一時的に休みなしに働いたとしても、そんなことが長く続けられるわけがないと思っているのです。

同じ価値観の人同士が一緒に働き、顧客とも価値観を共有できる、そんなそれぞれの価値観を実現する小さな会社が数多くあって、様々な人たちがそれぞれ自分に合った会社で働けること、そのことが働く幸せになる。

これらの文章に何かを感じたならば、本書を手にとっても損はないと思う。

PuTTY/Win7 – CentOS6/VMware のコネクションエラーについて

Windows7 をホストとする VMware Player にゲストとして CentOS6 を入れ、ホスト側から PuTTY を使い ssh 接続したとき、何も入力せずに放っておくと1分も経たずに接続が切れてしまう現象に遭遇した。とりあえずネットで検索してみたところ、まさに同じ条件の Q&A があった。

Putty Network Error: Software caused connection abort

この投稿に寄せられていた回答に従って PuTTY のドキュメントを読み直し、コネクションの keepalive オプションをデフォルト値の 0 秒から 20 秒に設定してみると切断することが無くなった。このオプションで指定した秒数ごとに NULL パケットを送出することで接続を維持するようである。ちなみにこの値を 30 秒にすると、また切断が発生するようになった。

参照した PuTTY のドキュメント項目はこれ。

10.14 ‘Network error: Software caused connection abort’

4.13.1 Using keepalives to prevent disconnection

今回のホストになっている Win7 から仮想ではない別マシンの CentOS に 接続したときはまったく問題が無かったので、VMware に関連した問題だろうと予想しているが、具体的な原因までは調べていない。

そもそもホストからわざわざ PuTTY 経由でゲストにアクセスする必然性は無くて、ゲスト OS のウインドウを開いて作業すればいいだけのことなのだが、これまでの端末経由での作業を継続したかったので、どうしても PuTTY を使える環境にしたかった。

GAE のアプリケーションを Marketplace に登録するときの注意点

Google Apps Marketplace にアプリケーションを登録しようとしてハマった。この Marketplace への登録についてはそれなりにドキュメントが揃っているのですぐに出来るだろうと思っていたが、かなり時間が掛かってしまったのでその経過をメモ。

まずは Marketplace のデベロッパ登録をするのだが、これについてはオリジナルの “Google Apps Developer Program Site” に加えて、”Google Apps Marketplaceにアプリケーションを登録する方法” や “Google Apps Marketplaceにアプリを公開するときに気をつけること” を参考にさせていただいた。これらのドキュメントにしたがって、Marketplace の Vendor 登録はあっさりと完了。

続いてサンプルアプリケーションを登録してみようということで、”Writing your First Marketplace App using Python” に掲載されているコードを使って、Google App Engine にアプリケーション環境を構築する。そしてこれを Marketplace に登録し、さらに Google Apps からアクセスできることを確認した。

本来はここで Google Apps のアカウントからアプリケーションを起動できるはずなのだが、どうしてもエラーとなってしまい期待した結果にならない。調べてみるとサンプルコードの federated_identity() が本来返すべき値を返さず None を返していることがわかった。OpenID まわりでうまく行ってないのだろうと推測するものの、どうすればいいのか分からないまま調べを進めていたら、”App Engine and Chrome Webstore Issues” に解決策があった。原因はアプリケーションではなく GAE の設定であった。GAE の Application Settings にある Authentication Options を (Experimental) Federated Login にすることで、Google Apps に組み込んだ自前のアプリケーションを動作させることができた。

結論:
Google Marketplace に登録するアプリケーションを Google App Engine 環境で提供するときは GAE の Authentication Options を変更する必要あり。

Google Apps の Gmail 設定について

Gmail ではデフォルトのメールアドレスに加えて、他のアドレスを使ったメール送信が可能で、このアドレスを何個か事前に登録しておくことができる。この機能を使ってデフォルト以外のアドレスを使って Gmail サーバからメール送信すると、メールヘッダの From: と envelope-from にそれぞれ異なるアドレスが設定される。この状態を避けて、From: と envelope-from を一致させたい場合は、From: に指定したアドレスの本来の SMTP サーバを使えばよい。この目的のために個人利用者向けの Gmail では、追加したそれぞれのアドレスに対して Gmail サーバ以外の SMTP サーバを設定する機能がある。

ところが Google Apps の Gmail ではデフォルトで SMTP サーバの設定が不可になっているため、どのアドレスを選択してもすべてデフォルトドメイン用の Gmail サーバから送信されてしまう。このようにして送られた From: と envlope-from が異なるメールを受信したとき、そのことを受信者に対して常に明示するメールツールがある。例えば Outlook2007 の場合だと、「xxx@foo.com が次の人の代理で送信しました:xxx@bar.net」というメッセージが表示される。利用者によってはこのメッセージ表示は好ましくないと考えるかもしれない。

この状況を避けるためには Google Apps の Dashboard → Email settings → General のところにある ‘Allow users to send mail through an external SMTP when configuring a “from” address hosted outside your email domains. ‘ という項目を有効にする必要がある。実はこの設定項目を当初見落としていたのだが、ヘルプフォーラムの記述によってその存在を知った。

http://www.google.com/support/forum/p/gmail/thread?tid=48b458471de77c9b&hl=ja
http://www.google.com/support/forum/p/gmail/thread?tid=2a5487be9d446a05&hl=ja

Android エミュレータの DNS 設定 — その2

前回の記事に書いた Android エミュレータにおける DNS 設定の件で、さらに理解できたことがあったのでメモ。プライマリの DNS サーバが落ちて名前解決が出来ていないときの状況では、net.dns1 の値が 10.0.2.3 になっているものの、net.dns2 には何も値が設定されていなかったことは前回にも書いた。

$ adb shell
# getprop net.dns1
getprop net.dns1
10.0.2.3
# getprop net.dns2
getprop net.dns2

#

たまたま入手した「ANDROID HACKS」(オライリー・ジャパン)によると、ここに出てくる 10.0.2.3 から 10.0.2.6 までの IP アドレスは、ホストマシンが参照している DNS サーバのエイリアスになっていることが分かった。したがって上記の状態ではホストマシンのプライマリに設定してある DNS しか参照しないことになり、該当する DNS サーバが落ちていたりすると名前解決が出来なくなってしまう。しかし net.dns2 に 10.0.2.4 を設定しておけば、ホストマシンのセカンダリ DNS 設定を参照するようになり、結果的に名前解決が可能になる。

#setprop net.dns2 10.0.2.4
setprop net.dns2 10.0.2.4
#

実際にこの手順で問題が解決したことを確認できた。ただしこのままだとプライマリの DNS が落ちているときは常に手動での設定操作が必要になり煩わしい。net.dns2 の値を恒常的に設定しておく方法を探す必要がある。

Android エミュレータの DNS 設定

突然にAndroid エミュレータがインターネットへ接続できなくなってしまった。調べたところまさに同じ状況についてのブログ記事があった。

Androidのエミュレータがネットワークに接続できない場合の対処方法

この記事によると、何らかの要因で DNS にアクセス出来なくなっているようで、手動で明示的に DNS を設定してやれば解決することが分かった。ちなみに自分のところでは net.dns1 だけ値(10.0.2.3)が設定されており、net.nds2 には何も設定されていなかった。上記のブログ記事のように Google の DNS を設定すると、確かにインターネット接続が可能になった。

ただ、これまではこんなことをしなくてもそのまま接続できていたのが、急に繋がらなくなったのが気になった。そこで本家ドキュメントを探してみると、Android エミュレータについての情報を見つけた。

Using the Android Emulator

このページの中盤あたりにある “Configuring the Emulator’s DNS Settings” によると、エミュレータはその実行環境で設定されている DNS を使うようになっている。問題のエミュレータは Windows7 上で動いているのだが、この Windows7 が名前解決に使っているプライマリの DNS サーバは、このところの計画停電に対応するため電源を落としていた。どうもこのことが名前解決できなくなった原因のようだ。

もちろん Windows7 環境では複数の DNS サーバを参照するように設定してあるので、プライマリの DNS サーバが無くてもまったく問題はない。当然 Android エミュレータも、親環境と同じセカンダリ以降の DNS を参照すればよいはず。しかしどうもこのあたりに問題があるようで、プライマリの DNS にアクセスできないと、Android エミュレータは名前解決できなくなってしまうようだ。前述のドキュメントによると Windows 環境では DNS 情報を GetNetworkParams() API によって獲得するとある。この API が複数 DNS に対応していないことは考えにくいので、恐らく Android エミュレータが複数 DNS 情報の扱いが出来ていないと思われる。