YAHOO APIで住所から緯度経度を取得できない場合は、GoogleのAPIで取得するように変えた。
郵便番号から緯度経度を取得してたけど、住所からもできるんだね。
しかし、Google Map geocording APIのリクエスト数が同一IPでは1日2500回しか、取得できないのは痛いなあ。
今日やったこと。
•表示されている範囲の緯度経度を取得する。
•地図画像サイズを変更する。
明日はマーカーを表示させてみたいけど、飲み会だから無理かな。
面白い本を買った。
「ドラゴン桜」や「エンゼルバンク」を書いている三田紀房さんが書いた本だ。
読みやすく買って1時間程度で読め終えてしまったが、とても内容は素晴らしかった。
「仕組みをつくれば残業は減る」
9時30分〜18時で、月曜から木曜までの週休3日制というルールを作り、週刊連載を2本あげれるようになったことを紹介している。
「時間をかければいいものができるという幻想を捨てる」
「練習なんてしていらないとにかくやってみろ」
なんて目からウロコのことを書いてあった。
自分はエンジニアでありアプリを作ったりするクリエイターでもあるが、このようになりがちだ。
悩んだり行き詰まったりしたときは、この本を読んでみるといいと思った。
『徹夜しないで人の2倍仕事をする技術三田流マンガ論 ─三田紀房流マンガ論─ 』 (コルク)
現場では総合試験の真っ最中。
テストのやり方なんだけも、ペアでテストを実施している。
一人がテスト内容を把握、操作を指示して、
一人が操作してシステムを動かし、エビデンスの取得し、結果を二人で確認するって感じ。
二人ぶんの工数が必要だが、意外と以下のようないい効果が出ている。
・ミスが少なくなった。
・ユーザーの業務内容について理解が深まった。
・ミスが少なくなった。
一人だと操作とテスト内容の確認をしているとごっちゃになって何をしていたか分からなくなることもあった。
例えば、一人で複数人のテストユーザーを用いてそれぞれの役割の操作をするときなど、
どのユーザでどこまでやったのか忘れちゃうなどあった。
それぞれの役割に集中できるため、負担が少なくなり。エビデンスの取り忘れや、操作ミスによるリカバリがかなり減った。
(二人ともかなりの集中力が必要になるため、疲れてくると見逃しちゃうこともあるけど、二人で共に反省できるのも大きい)
テストデータを間違って更新してしまうとリカバリのためにテストデータの状態を戻す予定外の作業が発生してしまい、時間のロスがないのは大きい。
また、作業者が再テストしたくないがために、「これは前にうまくいってたから、多分大丈夫だよね。」→でもデグレってて、後で発覚なんてことも防げると思う。
・ユーザーの業務内容について理解が深まった。
これはどんなときに使う機能なんだろうかとテスト前に議論することで、ユーザー業務内容の理解ができるようになった。
「じゃあ、システムはこういう使われ方をするはずだね。」とシステムを実際に使ってみると不便さに気づいたりした。
また、エラーにより業務が止まってしまう怖さを感じたりすることで、追加テストを自発的にやったりできた。
二人とも気が抜けないため、ヘトヘトになるが、すごく効果あると思う。
まあ、大前提として、無理なスケジュールが引かれてる必要があると思うけどね。
消化を目的としないとこなせない件数とかになると、上手くいかないからピリピリして人間関係悪化とか招きそうな気がする。