熊本地震支援の掲示板を作成

今度のゴールデンウィークは熊本地震支援のための掲示板サイトの構築に没頭しました。フルに10日間休みを取ったのですが、2日間を除いて残り8日はコーディングに明け暮れていました。

もとはといえば震災のある前の週にGoogleMapを使ったデモアプリを作ってみないかという誘いがK部長からあって、ちょうどその作業の最中に地震があったのがきっかけでした。
色々ニュースで、熊本の方ではとんでもない事態になっていて、支援物資を届けようと思ってもどこにどれだけの物資が必要になっているのかわからないということを言っていたのを聞いて、ひょっとしたら地図を使ってなにか役立つことができるのではないかとひらめいて始めました。

どれくらいで使えるものができるかわからなかったのですが、結局ゴールデンウィークの最後の日にリリースできました。途中ニュースを見ながら時々刻々とかわる状況を見ながら何回も方向転換を迫られ、結局復興状況を載せる掲示板ということにしました。pic3

コーディングに没頭すると周りのことが見えなくなるので、その間に家内がインターネットで見た色々なサイトのことを教えてくれました。その中で青年有志が作る「熊本大分支援コミュニティ」というフェースブックのページで、避難所や給水施設、GSなど様々な情報をGooglemap に載せてあるページがすごく刺激になりました。短い時間でそこまで情報を集めるのは相当なご苦労であったと思います。

少しずつ暇を見つけては今でも機能を更新していますが、なんにしても大切なのはコンテンツ
です。もし熊本・大分につながる情報があれば、ぜひ掲示板への投稿をお願いします。

掲示板サイトのURL は http://www.kumamon5963.jp です

 

必見:首相が高機能地図の必要性について言及

news20151004

今日のニュースで、安倍首相がオリンピックまでに車の自動運転を実現させようという決意を表明したとのこと。以下Yahooニュースからの引用

自動運転車はカメラなどで収集した周囲の状況を認識して走行する。首相は、自動運転に不可欠な高機能地図の開発について「日本には世界をリードしてほしい」と訴えた。

これから忙しくなるぞ。

machine-learning「機械学習」

coursera-machine-learning
「機械学習」という Stanford 大学の講座があったので受けてみました。8月終わりから9月の連休の終わりまで詰め込んで受けたので少々ハードだったのですが、非常に興味をそそられる内容でした。
内容を簡単に説明すると、人工知能のシステムをどのように作るかといったような内容でした。
例えばデジカメに実装されている顔認識、Amazon のようなショッピングサイトで使用されている商品レコメンデーションシステム、メールクライアントソフトの迷惑メール振り分け機能、最先端の応用例としては車の自動運転等、ありとあらゆる分野でこの「機械学習」というものが使われているようです。
コースの最初から数学の知識が必要でしたが、数Ⅲ程度のレベルしか持っていない私でもなんとかついていけました。コースは11週間かけて勉強するようなカリキュラムになっており、毎週1時間ほどのビデオでの講義のあとに小テストがあり、プログラミングの宿題が課せられています。
プログラムは MathLab または Octave という行列を専用に計算するような言語でしなければなりません。ほとんどの課題は数行書く程度なのですが、実際にC等で同等なコードを書こうとするとforループを含んだ行で10倍程度になると思われます。
理論はうわべだけ一通り学んだのですが、実際に使うとなると学習用のデータ集めから始めてきわめて地道な作業が必要のようです。

興味のある方は https://www.coursera.org/learn/machine-learning/home/welcome へ
講義は英語ですが、日本語の字幕もあるようです。 本屋で「機械学習」についてのいくつかの本を立ち読みしましたが、超難解でした、それに比べこのコースは実例を交えて講義を進めており、わかりやすい方だと思います。

「Interface」

本屋さんで興味を引いたので久しぶりに Interface という雑誌を買いました。
今回は画像処理のアルゴリズム「超解像」というやつで、低い解像度の画像を大きく引き伸ばす方法についての特集です。

中には次のような記事が載っていました。
普通画像を引き伸ばすと補間という方法を使うのが一般的ですが、補間だけで引き伸ばすと画像のぎざぎざが目立ってしまいます。今回の特集はその画像を引き伸ばすひとつの方法「超解像」というアルゴリズムについて解説です。画像のエッジを加味した補間法らしいです。

もうひとつはGPU付きのスパコンが2万5千円で買えるという話。もちろんワンボードのコンピュータではあるがUSB3、Ethernet、HDMI、SATA、イヤホンジャックが付いているというので周辺機器を買えばほぼ市販のPCと同じになるそうです。

今、新人にPCを組み立てさせる研修をしているけど、どうせだったらこんなものを使ってPCを作れといったら面白いかも知れませんね。

interface-2015-6

MVC

なんだか最近 MVC という言葉が聞かれなくなった気がする。もう浸透して語る必要がなくなったのか?それとも最近のWeb開発では向かなくなったのか?Model(データ) と View(見てくれ) と Control (制御) のコードを分けろということなのだろうが、言うはやさしくても、実際に実践しようとすると難しい。

画面を伴ったアプリケーションを作る際、データと表示の内容は当然ながら密接につながっているわけだが、プログラマから見て、データを変更する部分ではそのデータがどのように表示されているかはあまり考えなくてよいし、画面を作る側からはいつ自分が扱うデータ
以外については関心を持たなくてよいというように意識したコードが望ましいというわけだ。

最近VC++でMFCを使って書かれたコードを見ているが、若手が書いたコード(今からほぼ10年前のコードなので、今はみんな中堅なんだが)はMVCの基本を抑えていないものがほとんどだ。
たとえば ダイアログの「OK」ボタンのイベントの中で実際に目的とする処理が長々と書いてあったりする。処理時間が長いものをそのようにコーディングするのはご法度なんだが、それを正しい形でやろうとするとそこからとたんにハードルがあがってしまう。たぶん別に実行スレッドなるものを起こし、メインのスレッドとやりとりをしながら実行スレッドが終了するのを監視するようにするのが普通かと思われるが、では実行中にユーザになにか問い合わせて判断を仰ぐ必要があればとうする?とかを考えるとどんどん処理が複雑になっていってしまう。

この大変さはたとえ言語が変わっても変わらないので、UIを伴うコードを書いている人たちにとっては普遍の法則かもしれない。

ちなみに MVC を実現しようとすると一番 MFC が難しいような気がする。 MFC では最初に画面を作る際、ウイザードを使ってアプリケーションのフレームを作ることが出来るが、それがほとんど役にたったためしがない。MVC の概念がしっかりと学べるのは Java の Swing や SWT であると自分は思っているが、なにせマイナーなものなのでコードを見る機会は少ないかもしれない。

さすがPython

仕事でPythonを使い始めて1年半、今では数万行のコードになった。PythonはDOSとSQLで書かれたバッチ処理を新システムに移行する話が決まった時、お客さんに紹介して取り入れてもらった。

思いこせばPythonを最初に触ったのは4~5年前、C++やJavaに慣れていた自分にとっては、コードのブロックをインデントで表すなんてありえないと何年も食わず嫌いだったのだが、Googleで採用されているとか、スクリプト言語の中では一番早いとかいう噂でひとつ勉強してみる事にした。まあ色々癖や欠点はあるのだが、DOSコマンドに比べると格段にプログラムしやすい。おまけにGUIのAPIもデフォルトで付いている。

今回の仕事はDOSコマンドのスクリプトからPython に移行するだけだったのだが、ちょっとした工夫でコンソールアプリからGUIに変更することも出来た。自前でフレームワークを作りリスト系のアプリケーションならパラメタ項目の定義とSQLを記述するだけで簡単に作れるようになった。 アウトプットはCSVなのだが、ボタンひとつでExcel にも出力できる。さすがPython

PostgreSQL のパフォーマンスチューンではまった

データベースに PostgreSQL を使った業務が運用開始になり、ちらほら障害らしき問い合わせが来る。今までに来た問い合わせで一番致命的だったのが問い合わせのパフォーマンスが悪いというもの。以前 Oracle で同じアプリケーションを動かしたときには数分で応答が返ってきたのに PostgreSQLに載せ代えたら2時間たっても終わらないとのこと。

原因を調べてみると2つのテーブルをJOINしているクエリにやたらと時間がかかっている。
一部のSQLを抜き出し、PgAdminIII で実行してみるとJOINしているキーはプライマリキーで結果も1~2件しか返ってこないはずなのに9秒もかかっている。 Explain で見てもおかしく見えない。テーブルスキャンは使われていないのになんでこう時間がかかるのかわからず2日も費やしてしまった。
クエリプラン

インターネットで調べても、SQLを書き換えてテーブルスキャンを避け、インデックスを使うようにする方法はヒットするが、完璧に見えるPlanが遅いという事象はほぼないに等しかった。

いろいろ情報をあさりまくって、最終的にカタログの pg_statio_user_tables というビューでどのようにデータブロックがアクセスされているか調べることにした。そこでわかったのは、インデックスでアクセスされているはずのテーブルの heap_blks_read, heap_blks_hit などの数値がクエリ後でぐんとあがる。これはおかしい。

以前別なDBMSでパフォーマンスチューンでテーブルごとに統計を取る必要があったことを思い出しそれを実行してみるとクエリ所要時間が9秒から11msまで落ちた。

前の場合はプランが統計を採る前と後ではまるで変わったので、今回は統計を採る必要がないと判断したのが間違いだった。 PgAdminIII で表示される統計は実際の動作と違う場合があることがわかった。

今日は、全テーブルに一括して統計を採るスクリプトを書かないと…

PostgreSQL が面白い

ここ数年、業務で PostgreSQL を使用している。アプリケーションのDBMSとして使うのはもちろんだが、最近はデータベースそのものの構築を自動化することを行っている。

データベースの内部を触ることが多いので、テーブルの構造を持っているテーブル(カタログ)を調べて、テーブルが存在しているかどうかをチェックする機能を作ったりしているが、その中で PostgreSQL 固有の機能で面白い機能を発見した。

PostgreSQL ではほかのDBMSと同じようにスキーマという単位でテーブル等を管理している。スキーマが違えば同じ名前のテーブルが存在することが出来る。テーブルをアクセスする際、スキーマ名で修飾しないでテーブルをアクセスすると、セッションの search_path という変数で羅列したスキーマの順でアクセスするテーブルを検索する。

テーブルが存在するかどうかを調べるためにはこのsearch_path のせいで複雑なSQLを組まないといけないと思っていたのだが、最近発見したある機能で、テーブルの存在チェックを簡単に出来ることがわかった。

その機能とはテーブル名の文字列を regclass というタイプでキャストするということ。たとえばtable_a というテーブルがDB内に存在ししかもアクセス可能かどうかを調べるためには次のようなSQLを使用する。

select 'table_a'::regclass

こうするだけで結果としてそのテーブルの OID が返ってくる。もし存在しなければエラーとなる。(OIDが返ってくるのだが実際にpsql や PgAdminIII でクエリ結果として表示されるのはテーブル名そのものになっている)

これを応用して、どのスキーマのテーブルが実際にアクセスされているかどうかを調べるSQLは

select nspname from pg_namespace n, pg_class c
where n.oid = c.relnamespace and c.oid ='table_a'::regclass::oid

あとはこのSQLを組み込み、テーブルが存在しなかったときのためにエラー処理を入れればよい。

PostgreSQL ではキャストも独自で定義できるようだ。なるほどこういう使い方も出来るのかと目からうろこの瞬間であった。

技術部として投稿します

最近、社員ブログにITの投稿が少なくさびしいとMRの議事録に書いてあったので、微力ながらサポートしていきます。

いきなり技術的な話題に入るのもなんなので、年寄りくさいけど自己紹介から…

つい先日の誕生日で54になった。今思うと25歳の時にこの業界に入ってずっと今までひたすらにプログラムを書いてきた。いつも家族からは変人の部類に入っていると言われるけど、小さいときから変わったことに興味を惹かれていたように思う。

小学生のころは電気回路図が好きで、意味もわからないのにいろんな想像上の機械の回路図を書いては悦に入っていた。そのうちラジオやテレビの中身に興味をもちだし、ごみ捨て場に捨ててあるテレビの部品をよく拾ってきた。

コンピュータのことに興味を持ち出したのは短大の化学の先生に影響を受けてからだった。短大では英語を勉強していたが、一念発起してアメリカの大学でコンピュータを勉強しようと思い立って、カルフォルニアの大学に3年留学した。

帰ってきてからは新聞広告で小さなソフトハウスを見つけ、そこでアルバイトで働いた。その会社は今はないが、働いていた時の事務所は、今勤めているところの目と鼻の先にある。

そのころはプログラマの定年は35歳と呼ばれていた時期で、まさか54歳になってもプログラムを書いていることなどまったく想像できなかった。

そのときは年とったら何して生きていこうと真剣に悩んだけど、いまだに好きなコンピュータで仕事が出来ているのは非常にラッキーなことかもしれない。