まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2018/12

2018 年最後のブログエントリとして、今年を振り返ってみることにします。以下、基本的に箇条書きで:

【ブロックチェーン】
・自分的にはブロックチェーン技術を中心に学んだ一年だった
・開発業務で初めて使ったのは昨年。でも今年はプロジェクトリーダー的な形でも何度か
・今年はコミュニティを通じて色んな出会いがあった。ブロックチェーンだけでなく暗号資産(仮想通貨)のことも勉強できた
・ブロックチェーン/暗号資産は学んでいて楽しいと思える。技術者視点でワクワクする
・(一部の人にしか話したり見せたりしていないが)個人的に取り組んでいるプロジェクトがある。まだ改良を繰り返している段階だけど、公開できる段取りが整ったらまたいずれ


【仕事】
・仕事の拠点が箱崎から銀座へ移動。おっさんエンジニアには快適すぎ、むしろ戸惑う
・この1年で新たに学んだ技術。細かくは書ききれないけど主なものを列挙
 - Cloudant Design Document / PouchDB Sync / Geospacial Index
 - Chainer Gogh
 - Web Audio API
 - LIFF(LIne Frontend Framework)


【個人サービス】
マンホールマップ: 旧サーバーが昇天し、6年ぶりに新サーバーを構築して復旧。(嬉しくないけど)画像ごとデータベースに持たせる設計が報われた瞬間。最近のマンホールはアニメキャラクターものを中心に芸術作品としてのレベルが急激に上がっている印象、アクセスランキングにもその影響が表れている
ねっぴ: リアルタイム価格比較のスクレイピングが対策されてしまった。アプリケーションの Java から Node.js への移植はほぼ完成しているが、いたちごっこになるのを敬遠してどうするか迷っている
IDCF: 現在ねっぴを稼働させている IDCF から個人向けサービス終了のアナウンス。可能であれば継続したいと思っていますが・・・


【コミュニティ活動】
・自分が表舞台に立つ回数は昨年と比べてペースアップ。コミュニティ運営に携わる皆様、本当にお世話になっております&ありがとうございます
・github のリポジトリ増加数もペースアップ
・ブログの公開エントリ数減少、そしてボツエントリ(ある程度書いたけど公開をやめたエントリ)が急増。ちゃんと原因を調べてないのですが何らかの事情で公開に至らなかったブログエントリの数が例年と比べてやけに多い1年でした


【スポーツ・健康】
・大きな病気はしなかった。が、健康診断の結果は悲惨 (^^;
・週2のトレーニングは変わらず継続中。おかげでメンタル面は健康
・2011年の東京マラソン以来続いていた「毎シーズン何らかのレースに出場する」記録は途絶えそう


【大阪】
・宿泊を伴う仕事で十数度、プライベートでも数年ぶりに訪問。大阪近辺の路線図はかなり覚えたw
・勉強会を開いた時のフィードバックの量がダントツ。貴重な意見を多く取り入れることができる
・楽しい、空気があう、また行きたい


【2018 年新たに興味を持ったサービス】
・TikTok(つい見てしまう・・・。特別に目新しい技術ではないが、ユーザー体験が秀逸だと思う)
・Spotify(とうとう Premium 契約してしまった)
・PayPay(良くも悪くもだが、ほんの数日でサービスの知名度が上がったと思う)



【まとめ】
総じてよく勉強した1年だったと思います。コミュニティなどでその成果を共有する機会は増えました。一方でブログという形で自分なりに整理してアウトプットする時間はあまり取れませんでした。github のリポジトリはこの1年でかなり増えているので、2019 年の中でそのいくつかを紹介できればと思っています。


この振り返りを元に 2019 年の行動を変えていこうと思ってます。2019 年もよろしくおねがいします。


 

2018年にマンホールマップでもっとも人気のあったマンホール蓋をベスト10形式で紹介します。また今年新たに投稿された蓋の中で最も人気があった「新人賞」と、今年最も多くの蓋画像を投稿いただいた方「最多投稿賞」を紹介します。


集計のルールとしては 2018/01/01 から 2018/12/20 までの集計期間における、PC およびスマホのブラウザから単独ページとしてのアクセス数を集計しています。ページビューとしての集計なので、例えば同じページの画面をリロードした場合は1回とだけカウントされます。

なお、過去4回の結果はこちらを参照ください:


2018 最多投稿賞

今年マンホールマップに最も多くの画像を投稿いただいたユーザーに与えられる賞です。実は今年の(も)マンホールマップに有効に投稿された全画像の大半が昨年も激しく一位を争った minamu4545 様と 42ER03 様の2名のユーザーによって提供されたものでした。今年も感謝の限りでございます。 m(__)m

今年も昨年を上回るレベルでの激しい1位争いの結果、昨年惜しくも2位だった 42ER03 様が今年1年間で 355 枚もの蓋画像を投稿いただき1位となりました!2016 年の王座に一年ぶりに返り咲きました。「ほぼ1日1枚」でした、ありがとうございます。 

そして今年もハイレベルな一騎打ちを演出いただいた minamu4545 様、ありがとうございました。来年もお二人の争いになるのか、はたまた新星が現れるのか? 楽しみにしたいです。

ちなみに私自身は今年は4位でした。毎年少しずつ順位が下がっていたのですが、久しぶりに順位上昇でした。今年は出張が多かったからなあ・・・、しみじみ


2018 新人賞

今年マンホールマップに投稿された蓋の中で、もっともアクセス数の多かった蓋画像はこちらでした:

市区町村投稿者画像
千葉県流山市minamu4545



千葉県流山市「流山おおたかの森」駅にも象徴される TX(つくばエクスプレス)とオオタカ、そしてツツジがデザインされた新しいデザインの蓋です。私個人も大学時代に流山市に住んでいたのですが、当時は TX がまだ走ってなくて、流山の新しい風景がデザインされた蓋といえます。2018年1月にマンホールマップ投稿いただいたこの蓋写真が1年間を通じてもっとも多くのアクセス回数を記録する新人蓋となりました。minamu4545 さま、2年連続の新人賞おめでとうございます!


2018 総合ランキングベスト10

いよいよ 2018 年マンホールマップ年間アクセス数ランキングを発表する時がやってまいりました。総合ランキング1位となる MVM(Most Variable Manhole) の座はどの蓋に!?


まずは 10 ~ 4 位です。といいたい所ですが、僅差の11位の蓋をどうしても紹介したく、独断で今年はトップ11を紹介させていただきます。というわけで第11位!

順位昨年順位市区町村投稿者画像
11 - 静岡県静岡市morimo_t


↑マンホーラーの枠を超えて話題になった静岡県静岡市の「ちびまる子ちゃんマンホール」(morimo_t 様提供)。さくらももこ先生がこのマンホールのためにデザインし、残念ながらその設置の直前に亡くなられたことで設置の中止も検討されたというものです。今月からマンホールカードの配布も始まり、9月にデビュー(=設置)したとは思えないアクセス数が記録された一枚でした。改めて、謹んでさくらももこ先生のご冥福をお祈り申し上げると共に、素敵なマンホールデザインを残していただいたことに感謝申し上げます。


では改めてトップ10を。第9位が同数で2点あったので、第9位!

順位昨年順位市区町村投稿者画像
92北海道岩見沢市yanapong


↑同着の9位、1つ目は昨年2位の北海道岩見沢市(旧栗沢町)、yanapong 様提供の「リスのクリちゃん」マンホールでした。昨年まで3年連続トップ3という快挙を達成した超ロングセラー蓋です。今年9位になったことで、4年連続トップ10入りという、これも前例のない大記録を打ち立てました。


もう1つの第9位!

順位昨年順位市区町村投稿者画像
9 - 埼玉県坂戸市minamu4545


↑2つ目の同着9位は埼玉県坂戸市、minamu4545 様提供の「さかつるちゃん」マンホールでした。さかつるちゃんは坂戸鶴ヶ島水道企業団のマスコットキャラクターで「みんなのところにおいしい水を運ぶ水の天使」なのだそうです。このマンホールもマンホールカード化されています。


第8位!

順位昨年順位市区町村投稿者画像
8 - 神奈川県愛甲郡愛川町minamu4545


↑8位はこれも minamu4545 様投稿作品、神奈川県愛川町の、中津川、鮎、ツツジ、そしてカエデが描かれたデザイン蓋。デザイン的にもコントラストが美しい1枚です。なおこのマンホールもマンホールカード化されています。


そして6位も同着でした。1つ目の第6位!

順位昨年順位市区町村投稿者画像
6 - 静岡県熱海市minamu4545


なんとこれも minamu4545 様提供、静岡県熱海市の「金色夜叉」貫一・お宮の有名なシーンと、なぜかバックに上がる花火をまとめてデザインした一枚でした。今だとDV事案になる可能性もあるシーンですが、そんな時代背景的な要素も含めて表現されています。なおこれもマンホールカード化されています。マンホールカード勢、強いな・・・・


もう1つの第6位!


順位昨年順位市区町村投稿者画像
6 - 大阪府吹田市dotnsf


↑もう1つの6位は、、、ごめんなさい。僕の投稿作品でした。大阪市吹田市の吹田スタジアム近くに設置された suitable city マンホールの1つで、ここを本拠地とする GAMBA 大阪のマスコット「ガンバボーイ」と、吹田市のイメージキャラクター「すいたん」がデザインされています。これもマンホールカード対象です。

吹田市はこの蓋ともう2つの観光名所をテーマにしたデザインマンホール3種を今年公開しました。その中の1つがこれなのですが、実は結構探すのが難しい場所にありました。ネタバレありで詳しく知りたい方はこちらも参照ください:
吹田市のデザインマンホール3種を探索(ネタバレあり)


第5位!

順位昨年順位市区町村投稿者画像
5 - 静岡県沼津市minamu4545


↑5位は静岡県沼津市、富士山と愛鷹山をバックに松とハマユウが描かれたマンホールカード蓋です。なおこれも minamu4545 さんの提供作品です。この作品は 2018 年9月に提供いただいたもので、今回ランキング入りした蓋の中では比較的短期間で多くのアクセス数を稼いだことになります。



第4位!

順位昨年順位市区町村投稿者画像
4 - 東京都港区dotnsf


↑4位は、、、ごめんなさい。またも僕の投稿作品でした。2年前になぜか1位になった東京都港区の知り合いの家の近くで撮影したエバタインバート蓋。なぜここにアクセスが集まるのか、2年経っても全くわかりません。 (^^;


2018 年のアクセス数ランキング、ここまで minamu4545 様の提供のデザイン蓋が席巻しています。マンホールカードの広まりもあって、カラフルなデザイン蓋がマンホールマップでも人気を博している様子がわかりますね。


この流れはベスト3にも続くのか? ドキドキの第3位!

順位昨年順位市区町村投稿者画像
31静岡県静岡市minamu4545


↑3位は昨年1位と新人賞を同時受賞した minamu4545 様投稿の静岡県静岡市「かけつけ消防3部隊カワセミーズ」の消火栓蓋でした。2年連続のベスト3入り、つまり2年間に渡って人気が継続した蓋ということになります。

実はここまでの結果を見てもわかるのですが、今年のアクセスランキングは新人蓋(今年投稿された蓋)が上位を席巻しています。そんな人気の入れ替わりの激しい中でのこの結果は素晴らしいです。



第2位!

順位昨年順位市区町村投稿者画像
2 - 静岡県島田市minamu4545


↑2位は静岡県島田市の大井川蓮台越をテーマにデザインしたマンホールでした。この作品も minamu4545 様に提供いただいた作品です。

「箱根八里は馬でも越すが、越すに越されぬ大井川」とも詠まれた難所・大井川の川越えの様子が富士山を背景にしてデザインされています。ドリフやダチョウ倶楽部だとこの後の展開が容易に想像できますね(笑)。


では 2018 年マンホールマップ年間アクセス数ランキング・第1位となった MVM(Most Variable Manhole) は!?

 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓
 ↓


順位昨年順位市区町村投稿者画像
1 - 千葉県流山市minamu4545


↑1位 MVM は新人賞にも輝いた minamu4545 様提供の千葉県流山市、「流山おおたかの森」マンホールでした。2年連続の新人賞&MVM 同時受賞となりました。おめでとうございます。




ここ数年はマンホールカードの影響もあって、新しいデザイン蓋の人気が高いようです。今年のランキングにもその結果が表れています。そしてそれ故に、長い期間人気を維持し続けるマンホールがいかに貴重で素晴らしいかを改めて考えさせられる結果になりました。



そして、今年のランキングで無視できないのは minamu4545 さんの存在です。投稿数ランキングでは惜しくも2位でしたが、新人賞とトップ10内の7つ、そしてトップ3の全てを独占する形になりました。もちろんここまでの独占率を記録したことは過去にもありません。 現在のマンホールマップ人気蓋の多くをプロデュースしていただいております。本当に頭が下がります。


最後に開発者&運用者としての自分から。今年はマンホールマップサーバーが例年になく不安定であったと自覚しています。実はこのブログエントリを書く直前の 2018/12/21 にもサーバーダウンがありました。色々な事情(その多くはコストですが)からパブリッククラウドではなく自宅サーバーで運用しております。OS が落ちなければリモートメンテナンスできる環境は整えてあるのですが、今年はそのリモートメンテができなくなるケースが何度かありました。サーバー機、といっても普通のノートPCですが、の老朽化からディスクメディアが壊れ、冷却ファンが壊れ、これまでもだましだまし使ってきましたが、今年はその影響をユーザーの皆さんにかけてしまうことが多かったと反省しています。年末に新しい機材へ入れ替えを行い、少し安定することを期待していますが、そろそろパブリッククラウドへの本格的な移行も検討する時期かもしれない、と思い始めていたりします。 

一方で、今回の「新しい機材への入れ替え」は比較的スムーズに進んだと自負しております。自分のように自宅ネットワークを構築してサービスを運用する想定での工夫をしてきたつもりですが、今回のトラブル対応の中でやっとその成果を見せることができました(苦笑)。この辺りについては実績もできたことだし、近い内にまたブログで紹介できればと思っています。



では、来年以降もマンホールマップを宜しくお願いします。



グーグルマップは今やナビ代わりにも使えて非常に便利です。

この「グーグルマップでナビをする」という機能を一発で起動する URL を調べてみました。前提条件として GPS 機能が有効になったスマホのブラウザで起動し、現在地から目的地までのナビゲーションを行う画面にジャンプさせたいものとします。結論としては意外と簡単でした。

以下、いくつかのパターンの URL リンクを作成したので、このページを実際にスマホのブラウザで参照した後にリンクをクリックすると実際にナビゲーションを開始することができるので試してみてください。


【原則フォーマット】
具体例を以下に紹介しますが、原則的には以下のフォーマットの URL となります:
https://www.google.co.jp/maps/dir/出発地(/経由地のリスト)/目的地

出発地や経由地、目的地は 緯度,経度 で表します。

例えば(私の職場オフィスがある)東京の銀座シックスの位置は北緯 35.6696206 度、東経 139.7618279 度なので、35.6696206,139.7618279 と表現します。


【直接指定】
現在地から銀座シックスへの道案内は以下の URL です(経由地を指定していません):
https://www.google.co.jp/maps/dir//35.6696206,139.7618279

銀座シックスから東京タワー(35.658886,139.745787)への道案内はこちらの URL です:
https://www.google.co.jp/maps/dir/35.6696206,139.7618279/35.658886,139.745787


【経由地指定】
現在地から東京タワー(35.658886,139.745787)を経由して銀座シックスへ向かう道案内は以下の URL です:
https://www.google.co.jp/maps/dir//35.658886,139.745787/35.6696206,139.7618279

現在地から秋葉原(35.697850,139.771179)と東京タワーを経由して銀座シックスへ向かう道案内は以下の URL です:
https://www.google.co.jp/maps/dir//35.697850,139.771179/35.658886,139.745787/35.6696206,139.7618279


 

(この記事は IBM Cloud アドベントカレンダー 2018 に参加しています。3日目の記事です)

IBM Cloudant (Apache CouchDB) にあまり詳しくない人が他のデータベースと同じ感覚でデータを扱っている時に、特に既存データを更新している時にふと気づくことがあります。例えば以下のような現象を目の当たりにした時、何が起こっているのか正しく理解できるでしょうか?


IBM Cloudant のダッシュボード画面にアクセスし、今回は "testdb" という名称のデータベースを IBM Cloudant 上に新規に作成しました。以下の手順はすべてこのデータベースを対象に行います(CouchDB でも同様の結果になります)。作成したばかりなのでまだドキュメント数はゼロです:
2018100201


testdb データベースを選択した画面です。普通はここで testdb 内のドキュメント一覧が表示されますが、まだ1つも存在していないので "No Documents Found" と表示されています。ここでドキュメントを新規に作成するため "Create Document" ボタンをクリックします:
2018100202


新規に JSON ドキュメントを作成する画面に切り替わります。Cloudant(CouchDB) のドキュメントは "_id" というユニーク ID を含める必要があります(API 経由で _id を含めずに作ると自動的に割り振られます)。自動的に設定された "_id" 以外に "name" というキーを作り、適当な値(下図では "kkimura")を設定して "Create Document" ボタンをクリックします(JSON ドキュメントなので "_id" キーの最後にカンマをつけることを忘れずに):
2018100203


先程のドキュメントが作成され、ドキュメント一覧に1つのドキュメントが表示されるようになりました:
2018100204


ちなみに、この段階でデータベース一覧に戻ると testdb データベースのドキュメント数もゼロから 1 に変わっていることが確認できます:
2018100205


またドキュメント一覧からこのドキュメントを選択するとドキュメントの確認/編集画面になります。"_rev" という先ほど指定しなかったキーと値が追加されていますが、こちらは後で説明します:
2018100206


ここまでは特別におかしな所はないと思います。この文書を編集するあたりから Cloudant 特有のクセというか、「あれ?」と感じる所が出てくるようになってきます。

この画面から JSON ドキュメントを編集してみます。試しに "name" の値を(下図では "Kei Kimura" に)変更し、"Save Changes" ボタンをクリックします:
2018100207


変更内容が保存されて、ドキュメント一覧に戻ります。既存文書を編集して保存したので文書数は変わらずに1つのままです。ではこの文書を選択して開いてみます:
2018100208


"name" の値が "Kei Kimura" になった文書が開きました。が、よく見ると "_rev" の値が先程と異なっています。最初に作った直後は "1-" で始まる値だったのが、 "2-" で始まる値になっています。ここは変更しなかったはずなんですが・・・:
2018100209


また、このタイミングでデータベース一覧の画面に戻ると、testdb の文書数は1のままなんですが、データベースサイズが微妙に増えています。これほどの差がでるような変更をしたつもりはないのですが・・・:
2018100210


更にこの文書を開いて、再度 "name" 値を "kkimura" に変更して(元に戻して)みます。値を変更して "Save Changes" ボタンをクリックします:
2018100211


すると(中を開いて確認してもいいのですが)また "_rev" の値が変わっていることが一覧からもわかります。今度は "3-" で始まる値になっていました:
2018100212


この辺りから「???」と感じることが増えてきました。では最後にこの文書を削除してみます。一覧からチェックをつけてゴミ箱ボタンをクリックします:
2018100213


削除すると一覧からは文書は消えて、元通りの "No Documents Found" が表示されます:
2018100214


しかしデータベース一覧に戻って testdb を見ると、文書数は "0" ですが、横に!マークが付いています。また文書を削除した割にはデータベースサイズがあまり減っていないように見えます:
2018100215


この!マーク部分にマウスカーソルをあわせると、"This database has just 0 docs and 1 deleted docs" と表示されます。このメッセージの意味はいったい・・・:
2018100216


ドキュメントに勝手に "_rev"(と "_id")が付与されること、編集して保存すると "_rev" の値が勝手に変更されること、文書を削除してもデータベースサイズが減らないこと、文書を削除した時の謎のメッセージ、・・・ と、この辺りが Cloudant(CouchDB) を始めて使うと戸惑う点でしょうか? 前置きが長くなってしまいましたが、以下にこの謎を解くための説明を記載します。


上記の振る舞いを理解するには、まず自動付与される2つの値 "_id" と "_rev" の意味と役割を正しく理解する必要があります。

"_id" はいわゆる「文書 ID」です。この値はデータベース内でユニークな値をなっており、各文書を一意に取得することができるキー値となっています。正しい ID 値が与えられるだけで(他の絞り込み条件がなくても)データベース内から目的の文書を特定して取得することができます。ID 値については普通のデータベースでも扱うものなので、あまり難しくないと思っています。

一方、もうひとつの "_rev" 、こちらは IBM Cloudant(CouchDB) の特徴的な予約語となっており、「文書のリビジョン」を管理する値となっています。「リビジョン」は「バージョン」と読み替えていただいてもいいです。

上記の例だと、最初に "name" = "kkimura" という値で文書を作成しました。この時点ではこの文書のリビジョン(バージョン)は 1 で、"_rev" 値は "1-" で始まる値になっていました:
2018100204


次に同じ文書を "name" = "Kei Kimura" と変更して保存しました。この時点でこの文書のリビジョンは 2 となり、"_rev" 値も "2-" で始まる値に更新されました:
2018100208


更に同じ文書を "name" = "kkimura" に戻して保存しました。この時点でこの文書のリビジョンは 3 となり、"_rev" 値も "3-" で始まる値に更新されました:
2018100212


つまり "_rev" 値は "_id" 値で決まる文書のバージョンを管理する役割を持って自動的に更新されるシステム値ということになります。ただ Cloudant(CouchDB) でドキュメントが更新される際にはもう1つの特徴があります。

実は Cloudant(CouchDB) ではドキュメントが更新されることはほぼなく、「新しいドキュメントが新しい "_rev" 値を持って新規作成」されます。つまり厳密には同じ "_id" 値を持った複数のドキュメントがデータベース内には存在しているが、その中で最も大きな "_rev" 値を持ったドキュメントだけが有効になります。論理的にドキュメントを更新したつもりでいても、物理的には古いドキュメントは消えずに残っていて、新しいドキュメントが同じ "_id" 値&新しい "_rev" 値で作成されるのでした。なお最新でないリビジョンのドキュメントは _id 値を指定してドキュメントを取得する時に { revs_info: true } というオプションを指定することで取得することができます(このオプションをつけない限り、最新 _rev のものだけで取得できます):
http://docs.couchdb.org/en/stable/api/document/common.html


上記で Cloudant(CouchDB) のドキュメントが更新されることは「ほぼ」ないと書いたのですが、厳密にはあります。それが文書削除時です。Cloudant(CouchDB) の文書削除はいわゆる「ソフトデリート(論理削除)」であって、「ハードデリート(物理削除)」ではありません。文書に削除フラグ( { _deleted: true } )をつけて更新し、最新 "_rev" の文書が削除されているようにすることで、論理的に文書が削除されたことにしています。そしてこの論理削除を行う際には _id 値だけではなく、_rev 値と合わせて指定して、「この ID 値の、このリビジョンの文書を削除する」ことを明示的に指定する必要があります。論理的には _id 値だけで削除できそうな感覚を持ってしまいますが、その場合はまずその _id 値を持ったドキュメントの最新リビジョンを取得し、取得したドキュメントから _rev 値を取り出し、改めて _id 値と _rev 値を指定して論理削除する、という流れになります。


これらの部分を理解していると、文書を更新したり、削除した時にデータベースサイズが増える謎が理解できると思います。要は物理的に書き換えたり、物理的に削除しているわけではなく、新リビジョンのドキュメントを追加したり、削除フラグをつけたりしているだけなので、(別途物理削除するまでは)データベースサイズという観点では減ることがないのでした。








 

このページのトップヘ