2011年8月14日日曜日

Scrum Night Okayamaからの中国GTUG&オープンラボ岡山

勉強会は家に帰ってブログ更新するまでが勉強会です( ー`дー´)キリッ

というわけでIT系の勉強会とか集まりに参加してきました。
表題にある3件にこの金曜から土曜日にかけて参加しましたので感想記をばっ!

■Scrum Night Okayama
と言う名のただの飲み会でしたw
金曜日の19時からスクラムとかアジャイルに興味がある人の集まりであるすくすくスクラム瀬戸内の人たちで集まって呑みました。
実は自分は19時30分からだと勘違いしていてゲーセンで昇竜拳して遅刻したのは内緒です。
で実際の内容はと言いますとTwitterでは面識のあったけど実際にお会いしたことがなかった人や本当に新しくお会いした方などが居て女の子に囲まれてとても楽しい時間を過ごせました。
そして話の総まとめとしてはTDDBCを来年開催予定ですがそれまでの間に色んなとこで宣伝したりプレ開催的なものを年内でやっていければなと言った感じ。
なので自分が積極的に参加しているオープンラボ備後でもまたワークショップなどを交えてアジャイルな話をしていただければ嬉しいと思いました。

それと蛇足ですがきよくらさんが「ITクラスタによる格ゲー会をしたい」と熱望されておりました。
個人的には開催希望です!

でこの後は、ゼフィさんこと@zephiransasさんのお宅で二人で呑み明かしました。

■中国GTUG
3時まで呑んで7時半にちゃんと起きた俺を自分自身で褒めたいと思いましたw
二人して体調不良を訴えてましたが9時から始まるのでredbullを注入していざ会場へ。
自分は午前中だけの予定でしたので全くネタを考えてなかったのですが@zephiransasさんのネタに乗っかろうと思ってると気がつけばJSで作られたブラウザゲームで遊んでるだけになっちゃいましたw
だけど周りはゴリゴリコーディングやっててこれはちょっと気まずいので真面目にhtml5を調べてみることに。
html5とJSを使うと位置情報が簡単にとれるってのは本読んで知ってたので前回のブログで位置情報からの距離計算も生かせるしそれを使ってみることに。
参考にしたのはこちらのサイト。

デモ

で仕様については英語だけどW3Cのドキュメントをどうぞ。
で結論から言うと位置情報の取得は超簡単。
このデモのソースを丸々コピペしてローカルで動かしても動きます!!
自分はハッカソンにWindowsで挑んだのでXAMP使って再現したんだけどガンガン動きました。
ただChromeだとうまく取得出来なかったり、位置情報が自分の場所ではありえない場所を拾ってきたりすることもあるらしく実際にサービスとして開発するにはまだまだ仕様を煮詰める必要がありそうです。
興味がある人はデモのソースを読んで試してみるのがオススメです。
本当に簡単にできるので面白いですよ♪
と言うわけでデモから落としてきたら素直に動いたので自分はあとサーバ作ってましたw
ただやはり時間が足りない&PCの充電器を忘れて色んな意味で終了しましたwww
まとめとしては
  1. htmlの可能性はすごいけどしっかり仕様を理解する必要がある
  2. 今まで難しかったことが簡単にできるのは間違いない
の二点ですね。
午後からもハッカソンして発表も見たかったけど午後からはオープンラボ岡山に参加予定だったので後ろ髪引かれながら会場をあとにしました。

オープンラボ岡山
中国GTUGから会場が離れてたので少し遅刻してしまいましたが参加してきました。
項目は上記のラボのページの通りです。
ではセッション毎に感想を。

【タイトル】G1GC(Java SE 7のガベージコレクション)へ伸びていた「いばらの道」 【発表者名】中村さん(「ガベージコレクションのアルゴリズムと実装」の著者) 

最初の話を遅刻のため聞けず・・・rubyのコミッターの話なんて聞くチャンスがなかなかないので(´・ω・`)ってなりましたが中村さんは心優しく資料をうpしてくれてますので来てない人もどうぞ

で内容として特に感じるものがあったのは考えることをやめる=思考停止=プログラマーが死ぬとき。
自分も常々向上心を持たない人間についてdisってるけどこれは誰もがそうなる可能性を秘めてるよ!っていう問題提起とそれに対する自分が乗り越えた経験則からの対策が書かれていてなるほどって思いした。
こんな話をされてとても興味深い上に自分と同じ年でrubyのGCを作っちゃうような人なので是非とも懇親会でお話したかったのですがこの日は帰られしまいました(´・ω・`)

【タイトル】   MySQLの未来はどっちだ   - MySQL 5.6, MySQL Custer 7.2, MySQLでNoSQL
【発表者名】   日本オラクル   MySQL Sales Consulting Manager, Asia Pacific & Japan   梶山隆輔さん
最初はMySQLとかいってdisってやんよ!って思ってましたが最終的にはなるほど!って納得行く内容でした。
みんなsunが買収されて一番の関心はJAVAよりもmysqlだったと思うのですよ。
JAVAは無くならないけどmysqlはこのままフィードアウトしていくんじゃないかと。
だけどmysqlはシンプルで高速なDBってスタンスをWEBで生かしていくようです。
実際のWEBサービスも多くはMySQLですしそれで問題ありません。
現在の流行りである分散化KVSに対してのアプローチの話なんかも興味深く、今後のmysqlはWEBでの地位をより確固たるものにしていく気がしました。
逆にOracleDB自体は業務系の信頼性が必要な場面で生きて行くのだと思います。
そういう意味ではOracleDBとJAVAって組み合わせで業務系を作っていくのがひとつの完成形なのだと思います。
それに対してmysqlはWEB特化。
OracleDBが重厚すぎて手が出せない部分をmysqlが担っていくことで会社としての棲み分けが行える。
そして今後の期待できる部分はmysqlのエンジニアを大募集している点。
mysqlは企業が育てるOSSなので企業依存の部分が多々ある。
そこがOracleになったことで本気になった。
オープンソースの扱いは下手でもDBに関しては超一流のOracleがmysqlをOSSとして育てていくなら面白いソフトにならないわけがない。
実際にオプティマイザをOracleDBのエンジニアがチューニングしてたりするらしく5.6はとても楽しみです。
ついでにPostgresは業務系のOSSなどの万能DBのポジションになるんじゃないかな。
社内アプリとかで本番環境とlog集計がひとつのDBでやるときはPostgres。
つまり地方の中小企業こそOracleじゃなくてPostgres。
今後は3つのDBがそれぞれで棲み分けていくのかなと思います。


【タイトル】CodeIgniter入門
【発表者名】shoさん
phpのフレームワークのお話でした。
個人的にはValidationもMVCの仕組みも魅力的には映らなかった・・・
単発のアプリケーションならいいんだけどWEBサイトとしての運用を視野にいれるとちょっと運用に無理があるんじゃないかなぁと思った。
俺理論的には開発のためのフレームワークを使うくらいならCMSまで昇華させるべき。
単発のWEBアプリを作るなら必要最低のライブラリをあとから追加してスクラッチするのと大差ない気がした。
なのでWEBサイトはmagic3が最強。
その他サービスは現場はスクラッチでMVCで作る感じですかね。
ただ日本ユーザ会が活発で翻訳などが充実してるのはかなり高評価。
やっぱ日本語ドキュメントの有無が大事です(キリッ

【タイトル】「チャットワーク」でらくらく勉強会運営   ~「チャットワーク」インフラ担当者が裏側も紹介しちゃうよ!~
【発表者名】藤原さん
Amazonのクラウド環境とGAEを利用されたWEBサービスのお話。
無料枠でもすごく便利そうなツールなので今度DUELの打ち合わせとかで使ってみたいです。
そしてそれ以上に面白かったのはEC2とか使った運用の話。
なるほどって思う工夫とやっぱりかっていう苦労の両面が聞けてよかったです。
今までは仕事として使うのは不安だったけど要件次第ならどんどん活用していくべきかなと思った。
今後は本当のインフラエンジニアはクラウド先のインフラで生きるかデータセンターで生きるかみたいな感じになっていくのかも。
俺も会社の自社サーバは減らしたいしレンタルサーバだけじゃなくてGAEやEC2をもっと勉強しよう。


以上が感想記でした。
とっても充実してていつも以上に興味深かったOLOJPでした。


そして懇親会は中国GTUGとオープンラボ岡山の合同懇親会(略して合コン
いっぱい変態がGoogleTVに群がったり色んな人と面識が広がって充実してました。
そして一番の関心はやはりそーだいのOracle転職計画化w
Oracleレンジャーの漆黒のオプティマイザ!オラブラックとしてすっごく行きたい。
でも外資系だから当然英語は必要だし実力も必要。
行きたい行きたいって言っても採用試験に耐えれるレベルかというと自分としては疑問符がつくレベルなので要努力してからにしたいと思いますw
とりあえずmysqlを久しぶりに触ってみるかな(Postgresからの浮気フラグ

というわけでこの二日間、関係者のみなさん本当にお世話になりました。
とても楽しかったです!
次は9月はオープンラボ備後かな?
そのあとはOSC広島がありますので是非是非皆さん、ご参加してください!
それでは綺麗に?まとまったのでこのへんで。
ではではノシ

2011年8月11日木曜日

postgresqlを使った位置情報の計算について

仕事のヤル気がないのでブログ更新。
ちょっと休憩でブログ更新。

ちょうど今、仕事で緯度経度から位置情報の計算するプログラミングするのに基礎的な部分が気になったので数学を勉強しました。
元々「なんで?どうして?がおがおぶー!」(もうこの番組なくなっちゃいましたが)って感じで気になることはとことんやりたい人間なので位置情報はこの公式で出るんよ。ってWEBの情報で出てくると理由を調べたくなったのが理由です。
まぁ公式的にはこちらのサイト とかに書いてありますので興味がある人はどうぞ。
ついでに自分は正確性が求められるサービスでは無かったのでpostgresqlの機能とSQLで実現しました。
ソース的にはこちら

SELECT sqrt(power((対象緯度 - 自分の緯度) * 111, 2) + power((対象経度 - 自分の経度) * 91, 2)) AS distance
こんな感じ。
111と91は緯度経度の一度あたりの距離の近似値です。
詳しくはこちらのサイトが参考になります。
でテーブルに位置情報をもたせているならば
SELECT sqrt(power((hoge.lat - 33.333333) * 111, 2) + power((hoge.lon - 133.333333) * 91, 2)) AS distance FROM hoge 
ってするとhogeの中の位置情報を持った対象と自分との距離の一覧が出てくる感じです。
同じように位置情報で円を書いて絞り込みのwhere句を書くと
circle(point(対象経度 * 91.0, 対象緯度 * 111.0), 0) @ circle(point(自分の経度 * 91.0, 自分の緯度 * 111.0), 求めたい円の半径)
となります。
これをwhere句で差し込んだ例が
SELECT
  sqrt(power((hoge.lat - 33.333333) * 111, 2) + power((hoge.lon - 133.333333) * 91, 2)) AS distance
FROM hoge 
WHERE 
  circle(point(hoge.lon * 91.0, hoge.lat * 111.0), 0) @ circle(point(133.333333 * 91.0, 33.333333 * 111.0)
となります。
自分は緯度経度のカラムはNumber型にしてINDEXを貼っております。
これではベンチマークの結果、誤差がそれなりに出るようです。
そこをPostGISというライブラリがカバーしてくれるそうなので詳細なデータが必要な人は使ってみてください。
農研機構が使ってるらしいですよ(宣伝
ただPostGIS使ったりするとINDEXを有効利用してくれなかったりするらしいのでそこらへんの速度的な問題を解決してくれる人探してますw

####8/31追記 ここから####
INDEXについてツッコミをして頂きました。
アウトプットするとこうやってご指摘していただけるのでやっぱりアウトプットは大事ですね。
長方形の検索なら空間INDEXが有効なようです。
円は無理なのかな?
PostGISについてはもっと詳しく調べてみる必要がありますね。
####8/31追記 ここまで####


というわけでまとめ

モバイルWEBサービスなどで位置情報の連携を含めたサービスなどを作るときにコーディングの手間と集計を考えるとPostgresに位置情報を入れてDBで計算させるのがソースの可読性や運用面も踏まえてお手軽でいいのかなと思います。
クライアントさんに「ちょっとうちの会社から周囲〇〇メートルのお店のリストを表示させたいんだけど」的なこともSQLで実装できるので表示側はJAVAだろうがPHPだろうがRubyだろうが慣れた言語ですぐ実装出来ると思うのでみなさんの参考になれば幸いです。


さていい暇つぶしになった備忘録も書いたし盆休みに向けてラストスパートしたいと思います。
それではノシ