※このブログエントリーは「グローカルな仲間たち」が主催する年忘れサイエンス・サロン ～宇宙と機械学習を体感しよう～（12月27日（金））でのミニ講演で話した内容を再編集しまとめ直したものです。

寒い冬の夜、ちょっと不思議なサイエンスの世界に浸ってみませんか？今年の年末は、お酒を片手に科学を楽しむ特別なサロン会。かつてファラデーがクリスマスに科学実験で人々を魅了したように、私たちも科学の不思議と楽しさを分かち合う特別な夜を過ごしましょう！

という素敵な趣旨のイベントで、Scratchと機械学習について紹介してほしいという依頼を12月上旬に受けました。

もうひとつのトークである「ゆうこ先生と宇宙 -折り紙で宇宙を表現する」では、元JAXA研究員で宇宙と科学を紹介するプログラムをこどもたちに届けているゆうこ博士と、地球以外に知的生命体は存在するのか？といったことを議論したり、折り紙でIKAROSの電力セイルの構造を折って学んだりして、好奇心をとてもくすぐられました。

さて、その依頼というのが、原文ママ載せると

「猪木」の顔真似をして、どこまで「猪木」になったのかということを数値で測ることはできるのでしょうか（笑）

参考: アントニオ猪木

というものでした。

Scratchの独自拡張機能で、カメラに映した画像があらかじめ学習させた画像のどれに近いかを判定できるML2ScratchやTMScratchを利用すればできそうですが、顔の特徴点をもっと精密に推定できるFacemesh2Scratchを使ったほうが精度良く作れそうだと思ったので、今回はこちらを紹介することにしました。

ScratchのMODである

Stretch3: https://stretch3.github.io/

を使います。Facemesh2Scratchはじめ、先に紹介したML2ScratchやTM2Scratch、さらに他の機械学習を使った独自拡張機能を使うことができます。

基本的な機能を紹介するサンプルプログラムがFacemesh2Scratchのページにあるので、これをベースにして作っていきます。

https://github.com/champierre/facemesh2scratch

を開いて、サンプルプロジェクトの最初の random.sb3 をダウンロードします。

Stretch3 のメニューで ファイル > コンピューターから読み込む を選んで、ダウンロードした random.sb3 を開きます。

緑の旗ボタンを押してプログラムを実行すると、以下のように自分の顔の上のあちこちに黄色いボールが表示されます。

これで準備ができました。

さて、「猪木」の顔真似をしてそれを数値で表示するということは、これは「猪木」顔かどうか？を判定できるということです。数値で表すより、「猪木」顔であれば「猪木」に変身できるという方が楽しそうです。

ということで、紹介するプログラムの内容を

「猪木」顔だったら、「猪木」に変身できる

と再定義します。

では、「猪木」顔というのはどういう顔なのでしょうか？

「猪木」とは、、、

あご

ですね。

あごがいつもより伸びていたら「猪木」に変身できるようにしましょう。

プログラムを実装するには「あごがいつもより伸びたら？」を厳密に定義する必要があります。

Facemesh2Scratchが内部で使っているFacemeshは、顔の上の468ヶ所の特徴点の位置を推定することができます。以下が、各特徴点が顔のどの部位にあたるかを示す図です。

出典: https://github.com/tensorflow/tfjs-models/tree/master/face-landmarks-detection

図によると、たとえばあごの一番先は152となっています。

random.sb3のプログラムを以下のように変えます。

1から468までの乱数を keypoint という変数にセットしていたところをやめて、153固定にすることで、153番目の特徴点にだけ黄色いボールを置くようにしています。見やすいようにボールの大きさは40%に変更してあります。また、Facemesh2Scratch ではわかりやすさを優先して、特徴点の番号を1はじまりで468までふっているのに対し、もとの Facemesh の図では0はじまり、467までの番号がふられているので、図では152番目でしたが、プログラムでは1だけずらした153番目に設定しています。

緑の旗ボタンを押して再度実行してみると、以下のようにあごの先にだけ常に黄色いボールが表示されます。

プログラムを少し解説します。

の部分で、keypoint という変数に153をセットし、そのあとで黄色いボールのx座標を1人目の keypoint (つまり153)番目の部位のx座標に、y座標は1人目の keypoint (=153)番目の部位のy座標にあわせています。これを「ずっと」おこなうことで、常に黄色いボールは153番目の部位、つまりあごの先を追いかけることになるのです。

Facemesh2Scratch では顔の各部位のx座標とy座標を取得できることがわかりました。

であるならば、「あごがいつもより伸びたら？」を判定するためにあごの長さを求めれば良さそうです。

あごの長さとは？

ここでは、あごの長さとは、

鼻下のy座標 - あごの先のy座標

と定義することにします。

先に登場した各特徴点が顔のどの部位にあたるかを示す図によれば、鼻のすぐ下は164(Facemesh2Scratchでは165)です。

以上をもとに、あごの長さを常に表示するようにプログラムを書き換えます。

緑の旗をクリックして実行します。

普段のあごの長さ40近辺ですが、

「猪木顔」をしてみると、あごの長さが49まで上がりました。

あごの長さがたとえば 45 以上になったら、猪木に変身するというプログラムを書けばうまくいきそうです。

ところがこの方法には欠陥があります。

この長さは、画面上での長さなので以下のように顔をカメラに近づけてしまうと、猪木顔でもないのにあごの長さは長くなってしまうのです。

カメラからの距離に関係なく、あごの長さが普段よりも長くなったら？を定義するにはどうすればいいでしょうか？

それには長さが変わらない顔の他の部分と比較すれば良いのです。

顔の他の部分で長さが変わらない部分とは？

縦幅に比べてなかなか変えることができない横幅などいろいろあるのですが、ここでは、右目頭と左目頭の間隔を使うことにします。

再び各特徴点が顔のどの部位にあたるかを示す図によれば、右目頭は133(Facemesh2Scratchでは134)、左目頭は362(Facemesh2Scratchでは363)です。

右目頭と左目頭の間隔は、

右目頭のx座標 - 左目頭のx座標

で表せます。

あごの長さが目頭間の距離の何倍長いか？という比率は、同じ状態の顔であれば、顔がカメラに近くても遠くても変わらないはずです。

そこで、

あごの長さ / 目頭間の距離

を常に表示するようにプログラムを変更しました。

あごの先に黄色いボールを表示するのはもう不要なのでやめています。またわかりやすいように目頭間の距離とあごの長さを表示するようにしていますが、これはデバッグ用の別のコードで実現しています。（最後に掲載するサンプルプログラム inoki.sb3 に含まれているので興味があれば参照してください）

通常だと あごの長さ/目頭間の距離 は 1.8 くらいですが、

猪木顔をすると 2 以上になりました。

カメラに顔を近づけても、遠ざけても変わりません。

敷居値を2にしておいて、それ以上になったら猪木に変身する、というようにすればうまくいきそうです。

もしあごの長さ/目頭間の距離が2以上になったら、「猪木」というメッセージを送るようにします。

こちらが「猪木」のメッセージを受け取る側のプログラムです。普段は表示されていませんが「猪木」のメッセージを受け取ったら表示して、5秒後に再び隠すようにしています。

実物の猪木の顔が写っている素材はフリーで利用できるものが見つからなかったので、photoAC の

https://www.photo-ac.com/main/detail/3253627/

にあったフリー素材を使っています。

猪木顔をしたら、猪木に変身できるようになりました。

紹介した猪木に変身できるプログラムは、以下リンク先からダウンロードできるようにしておきました。

https://github.com/champierre/facemesh2scratch/raw/master/sample_projects/inoki.sb3

Stretch3: https://stretch3.github.io/ から開くことができます。

このエントリーを参考にして、Facemesh2Scratch を使ったほかに面白いプロジェクトができたらぜひハッシュタグ #facemesh2scratch をつけて Tweet したりして教えてください。

This is English translation of 東京にいながらにしてインターナショナルな環境でプログラマー(Rubyist)として働くというお話 that I wrote in 2015. The translation is provided by ChatGPT.

The day of RubyKaigi has come around again this year.

After RubyKaigi ends, it's almost a tradition for everyone to say, 'Ah, I wish I could speak better English.' My first time attending a Ruby conference was already 7 years ago, and compared to back then, the number of participants from overseas has greatly increased, and nearly half of the sessions are now in English. Amidst this, I, among others, have realized our own shortcomings in English proficiency.

I want to recommend a method for such people: working at a company with a development team composed of international members. I'll write about my experience working as a contractor helping with development at MediWeb as an example.

Since September, I've been under the care of MediWeb and participated in RubyKaigi as a Gold Sponsor, so there's a sense of gratitude, but it's purely my personal opinion that this way of working is pretty good for engineers, so I'm introducing it on my personal blog.

You can get accustomed to English

First, let me introduce my background. From 2000 to 2004, I worked as a QA engineer doing internationalization and localization at a software company based in San Francisco. So, I have some experience working as an engineer in English. However, my colleagues weren't native speakers but software engineers from Russia and Ukraine, so the easiest English for me to understand was with a Russian accent. I think I can speak much better than the average person, but my self-assessment is that I didn't improve much despite living there for four years.

Moreover, my English skills had fallen quite a bit due to a break of over ten years, but after working at MediWeb for three months, I feel like I'm getting back to my old level.

We're developing a cloud service called 3Bees for clinic reservation and queue management using Rails, and the code to be deployed in the production environment is always written through pair programming. The development team members are from diverse countries like France, Ukraine, Poland, America, and Canada, and I pair up with different members. Although some are fluent in Japanese, almost all communication is in English, and even lunch with the development members is English only, so it's like having free daily English lessons. Also, comments in the source code, PR comments, etc., are all in English by default.

Honestly, the first two weeks were almost feverish, but now I've gotten quite used to it. While some people pay to study English in the Philippines, I think it's a very advantageous environment to be paid while learning English.

You can experience a sense of humor and various values that are new Development is conducted according to the scrum method, and since one week is one sprint, we review every Friday and plan afterward. Sometimes we celebrate with a beer or two in the office.

When I'm a bit tipsy, I can talk much better, and during such times, a video was introduced when discussing how difficult the French R sound is for Japanese people ↓

Ah, I laughed a lot at this, but this sense of humor is a bit different from the Japanese, which is interesting. There were also pranks from some Nordic comedy show and when I was struggling with CSS, a Gif like this was sent in Slack.. I don't know how to describe it, maybe it's classy or witty?

View post on imgur.com

There are things that I don't get at all, but including those, I think it's good for those who can enjoy them.

No Japanese blackness

I'm quite reserved by nature, and I tend to worry too much. If someone says something harsh, I take it to heart, and I often wonder, 'What does that person think of me?' However, when I was working in America, I honestly couldn't guess what the other person was thinking, so I didn't need to worry about that, and I remember it being comfortable in terms of human relationships.

Working in an international development team gives me a similar feeling, which is nostalgically comfortable for me.

The first company I joined after graduation was quite Japanese in nature. If a boss said 'Let's go drinking,' it was obligatory. I had experienced customs like pouring beer with the label facing up in a university sports club, and while it was fun and not a hardship, to continuously stay calm, a Western-style dry relationship seems more suitable. I think many software engineers share this value.

There's a value in respecting each other's time, and leaving work on time is considered good. If you're sleep-deprived, overworked, and not performing well, you're not seen as professional.

There's a strong sense of professionalism and consciousness of team development.

Code is always done in pair programming, and Pull Requests are always reviewed by someone not in the pair, maintaining an atmosphere of strictly adhering to the rules of development. When I worked in America, I always thought that everyone followed the rules properly. The reason isn't clear, but it may be because, in both America and in international teams, when people from various backgrounds with different values work together, the only common ground becomes the explicitly stated rules, so they are followed more strictly.

In a Japanese context, there's a tendency to say, 'We don't have to be so rigid,' or 'Let's be flexible, this is an exception,' leading to a gradual increase in exceptions and eventually breakdown. On the other hand, by gradually optimizing the rules and strictly adhering to them, especially in software development, things start to run very efficiently.

Contradictorily, in a good way, to being dry, there are many moments that make you feel like you are really part of a team, like light celebrations at the end of a sprint, or ordering pizza for everyone in the office when we couldn't have lunch due to an issue.

On birthdays, there would be a Pull Request assigned to me that I didn't remember, and when I opened it, it would contain something clever like this ↓. It's a nice touch.

Conclusion

If you're working as a software engineer, working for an overseas company might be environmentally better. For example, living and working in America can be challenging, especially if you have children and need to think about their education. Additionally, while San Francisco is somewhat better, the food isn't great.

If you work for a company with an 'international team,' you can enjoy the benefits mentioned earlier while living in Tokyo, where there are plenty of delicious places and in the safe environment of Japan.

There are international companies that develop using Ruby/Rails, so if you think the environment I've described suits you, why not try working for such a company?

MediWeb is one of these companies, and at RubyKaigi, you'll likely see members of our team. I'll be there too, so if you're interested, mention me at @jishiha, and I'll introduce you to what it's like to work there and connect you with the development team.

Or if you're seriously interested in formally contacting us, go here ↓

» MediWeb | Medical Cloud | Recruitment Information

クイズです。

配列内の特定のオブジェクトの次(next)と前(prev)を取得する処理で、 JavaScript では、

array = ['a', 'b', 'c']
target = 'a'
prev = array[array.indexOf(target) - 1] // undefined が返る
next = array[array.indexOf(target) + 1] // 'b' が返る

のように想定通りに動くのですが、Ruby では

array = ['a', 'b', 'c']
target = 'a'
prev = array[array.index(target) - 1] # ????
next = array[array.index(target) + 1] # 'b' が返る

想定どおり動きません。

なぜでしょう？JavaScript と Ruby 行き来しているとはまるな、これ。

額縁に入れて飾りたい

If you're unable to create a majestic monolith with basic programming tools like encapsulation and namespaces, you don't have what it takes to improve upon the situation with a distributed swarm of microservices. Your spaghetti code will just be on five different plates.

— DHH (@dhh) June 21, 2023

ChatGPTの訳 基本的なプログラミングツール、例えばカプセル化や名前空間を使用して壮大なモノリスを作る能力がないなら、分散マイクロサービスの群れで状況を改善する能力もありません。あなたのスパゲティコードは、ただ5枚の異なるプレート上に存在するだけになるでしょう。

microservices で開発できるためにスキルを上げましょう、って言っているのではなくて、DHHほどのスーパープログラマでないほとんどの人は monolith で作ったほうが良いよということなのだと思います。

これまで何回か振り返りを残しているので、1週間経ってしまいましたが記憶が残っているうちに今年の Scratch Day in Tokyo でおこなわれた Show & Tell を振り返ります。

これまでの振り返りは以下の通り。

• Scratch Day in Tokyo 2019 Show & Tell 振り返り
• Scratch Day in Tokyo 2017 振り返り
• Show & Tell(ショーアンドテル) at Scratch Day Tokyo 2015 振り返り
• Show & Tell(ショーアンドテル) at Scratch Day Tokyo 2014 振り返り

Keep（来年も続けたいこと）

• MC御家さん、場を盛り上げてくれるし（ネコ大砲では盛り上げすぎでしたが :) ）、うまく質問をひろってくれる上に、今年はタイムキーピングまでもやってくださった。なくてはならない存在です。
• 会場からどんどん質問が出る。誰もが登壇者と同じ Scratcher であるからならでは。
• CoderDojo吉祥寺の山浦さん発案の登壇者専用名札。だれが登壇者かわかりやすいし、これを渡す過程でだれが会場にすでに来ているかがわかって出欠チェック代わりになる。
• それぞれの部の全作品を、別タブで開いておいたので、進行はスムーズだった。
• 応募作品はすべて採用

Problem（問題点）

• 動画で配信する旨を直前に登壇者に伝えることとなってしまい、一部の作品でタイトルやクレジットの表記の調整をお願いすることになったり、配信内容を調整する必要が生じてしまった。
• これまで応募者がどんな人であるかということは全く問わず、基本的に応募作品はすべて採用という方針を取ってきて、例年様々な年齢、男女の作品が発表される結果となってきてはいたのですが、今年は確かにかたよりがあると思いました。

  スタッフは女性も多かったのであまり意識していなかったのですが、Show&Tellは女子は娘だけでした👀
  娘はScratch歴7年にもなりますが、難しいものを作るわけではなく、好きな絵を描いて動かす、という創作をずっとブレずに楽しんでいます。
  そういうゆるい作品もありなのでみなさんぜひ🥰

  — rinyanyamama (@rinyanyamama) May 23, 2023

• 年々作品のレベルが上がってきており、前回開催から4年が空いてますますプロ顔負けの作品が多くみられたのですが、そうなってくるとまだ Scratch をはじめてまだ少しなんだけど、といったこどもたちの発表がしづらい雰囲気になってしまっている気がする。

Try（来年改善したいこと、やってみたいこと）

• 動画で配信する旨は応募フォームにちゃんと書くようにします。また、細かくなってしまいますがその際に注意すべきこと（使用する素材やBGMの使用許可の確認）も併記します。
• 過去の振り返りを読み返してみると、ほぼ毎回のように書いているのに実現していないどんな作品でもOKというもっと誰でも参加しやすい別枠の Show & Tell を用意します。 動画配信はなし、会場だけで楽しむ場とします。
• 振り返った内容を活かせるよう、来年の Scratch Day が近づいたら、このブログ記事を読み返すこと。
• タイマーは御家さんが用意してくださったアプリを使っていたけど、そこは Scratch 製のものを使いたい。

シンギュラリティなんてSFの話だと思っていたが、ん、これもしかして本当にその日は来るかもと思った実体験を紹介します。ChatGPTがすごいという話をよく聞きますが、一方でひっかけ問題にはやっぱりひっかかったとか、某社の創業者の名前を間違えたとかまだまだ信用できないという評価もあります。

いやいや、そんなググったら一発でわかるような問題を聞いてどうするんだと思います。位置情報をJSON形式で記録でき、地図アプリとかに表示するときに便利なGeoJSONというファイルフォーマットがあります。

観光地のサンプルをいくつかリストして、このGeoJSON形式のファイルとして生成したいと思ったのでChatGPTに頼んでみました。「日本の観光地を10個含んだ geojson を作って」

その後この GeoJSON ファイルを使用する地図アプリの都合上、properites のキーの名前が都合が悪かったので、変えるようにお願いします。

ばっちり修正してくれて、この時点で驚きました。しかし表示してくれたサンプルには2つしか実際のデータがなくて、残りは ... でごまかされていたので以下のように指示しました。 「...の部分は省略せず、サンプルでいいので実際のデータで表示して。」

追加要望も難なく受け付けてくれます。

きちんと丁寧に指示すれば、かなりややこしい要望にも応えてくれます。

しかし、写真のURLは実在しないものででっちあげでした。「写真のURLは実在のものを使って」とお願いしたところ残念ながら断られてしまいました。

しかしここまでの成果で上出来です。実際に自分で作業してこの結果を得るのは、さして難しいことではないとはいえ、小一時間はかかるのではないでしょうか？それがものの数分で終わってしまいました。

昭和の話をします。いや、僕が働き始めたときはもう平成だったので平成時代の話です。社会人1年目、2年目の頃というのは、議事録をまとめたりとか、何らかの報告書の草稿を書いたりとか、あるいは顧客への謝罪メールの下書きを書かされ全部書き直せとか言われたりといった雑用をまかされます。

そうした泥臭い経験を積み重ねることで社会人として成長していくと思うのですけれど、そうした雑用レベルのタスクが今後どんどんAIに置き換えられてしまうとすると、これから学ぼうという人たちの成長の機会が奪われてしまうのではないかと思ってしまうのですが、それが杞憂に終わるといいなと思います。

Amazonのページで本を検索すると、最寄りの図書館にその本があるかどうかをAmazonのページに表示してくれる Libron を更新しました。10年以上メンテしているので僕には今さらなのですけど、時を経てこのツールを知らない人もでてきたと思うのでいまいちど紹介したいと思う。

どんなツールなのかはこのアニメーションgifを見てもらうのが一番てっとり早い。

このAmazonのページから別のページに移動する必要がなく、ページ上にその本が図書館にあるかどうかを表示してくれるところが、Libronを人に見せると「どうやってるの？」と驚かれるポイントだ。Chromeの拡張機能を使うとこれが実現できる。

Amazonの本のページのURLには、ISBNコードという各書籍にわりふられたユニークな番号が含まれており、各図書館の検索ページでこの番号を検索すればその図書館に本があるかどうかがわかる。この作業を超高速にプログラムが裏でやってくれて結果を表示するということをLibronはやっている。

さて、全国には7400以上の図書館があり、図書館の検索ページの仕様はおおまかには似通ってはいるのだが、微妙に少しずつ違っている。最初は地道に、僕が住んでいる調布市を中心に少しずつ対応範囲を広げていったが、他県で対応してくれる協力者が現れていったとはいえ10県くらいで発狂しそうになった。

そんなときに登場したのが https://calil.jp という画期的なサービスで、この気の遠くなる地道な作業に本気で取り組み事業化している。図書館に蔵書があるかどうかの結果をAPIとして提供しており、LibronはカーリルAPIを利用する形に変更した。

2010年よりAmazonのページは何度となく細かな部分が変わっており、その都度ちまちまと修正してLibronを対応させてきた。12年間メンテし続け今でも動いているということは、12年後も高い確率で動いているということだ。この間類似のツールはいくつかでてきたが、それらにはない老舗の利点と言える。

今Amazonで本のタイトルを検索すると、実はKindleのページがヒットする。そこから、同じタイトルの単行本のページに移動しないと蔵書検索して結果を表示できなかったのだが、今回のアップデートでKindleのページでも先回りし、図書館にその本があるかどうかを調べられるようにした。

Libronを外国の人にデモする機会があり、そのときに「How slick!」というコメントをもらった。聞き慣れない単語だなと思ってそのとき調べたら、「（表面が）ツルツルした」「滑らかな」という意味から転じて、「洗練された」とか「巧妙な」という意味があるらしい。

以来、僕はこのslickさをソフトウェアやプログラムを作るときの大事なポイントに置いている。AmazonのKindleのページから単行本のページにはボタンをマウスでクリックすれば移動できるが、そのボタンのリンク先の情報をプログラムを書いて自動で取得すればその1クリックの手間を省くことができる。

そうしたちょっとした手間の省略を積み重ねることで便利なシステムやソフトウェアができあがる。最近になって耳にするDXというキーワードも、なんてことはない、この手動でおこなっているひと手間ひと手間を自動化していって、ピタゴラスイッチのように連携してうまく動くようにすることに過ぎない。

Chromeの拡張機能というのは、このようにとても便利でパワフルなものだが、裏を返すとなんでもできてしまう、それこそパスワードの欄に打ち込まれた文字をどこかのサーバーに送るなんていう悪行も可能だ。拡張機能を使うときはその作者、開発者を信頼して使うしかない。

Libronの場合も僕を信じてください、と言うしかないのだが、加えて、拡張機能のソースコードは https://github.com/champierre/libron で公開しており、見る人が見れば、この中で不正なことをしているかどうかはわかるようになっている。

また、もし僕が飽きてしまったり、やる気がなくなっても、あるいは明日急にトラックに轢かれてしまっても、このソースコードを誰でも引き継ぐことができる。

自宅は集合住宅で、はじめから各部屋にLANポートが付いていて、契約すればNTT-MEが提供しているインターネットサービスを利用できるようになっている。

このほど、IPv6接続サービスを提供開始しました、というお知らせが来た。動画や大容量のデータでも快適に利用できると謳っているので、申し込もうと思いホームページを確認してみたのだが良くわからない。そこでカスタマーサポートに確認したら、別に申し込みは不要で、IPv6で接続するにはルーターの設定を IPv6 > パススルー有効 にすればいいだけですよ、と教えてもらったのでさっそく設定してみた。

ちょうどつい昨日、無線ルーターを TP-Link Archer AX73/A に変えたばかり。管理画面から IPv6 のメニューを探しだし、パススルー（ブリッジ）を有効にした。

設定を変更する前と後で特段速度は変わらないし、ちゃんと設定が有効になっているのか不安だったのでちょっと調べてみたところ、「あなたの IPv6 をテストしましょう。」というサイトで確認できるとのこと。

こちらが IPv6 パススルーを有効する前↓

こちらが IPv6 パススルーを有効にした後↓

ちゃんと有効後は IPv6 で接続できていることが確認できました。

速度を計測するときよく使う https://fast.com にアクセスして詳細情報をみると、パススルー有効後は IPv6 のアドレスが表示されるようになるのでここでも確認できます。

IPv6 パススルーを有効にすると、v6 とはいえ生のIPアドレスが外にみえてしまう（IPv4 の場合は通常は NAT 越しになるためプライベートアドレスは外には見えない）ので、セキュリティ的に大丈夫かよ？と思ったのだが、SPIファイアウォールとともに使えばまあ大丈夫、とのことらしい。

さて、IPv6 パススルーを有効にすると動画などが快適に見られるようだが、果たしてその効果はどうなんだろう？ Netflix や Amazon Prime などストリーミングサービスを観ているとき、たまに切れることがこれまではあったので、それが少なくなることに期待したい。

AEDの設置場所や避難場所などのデータを各自治体が積極的に公開するようになってきました。これらはオープンデータと呼ばれており多くはCSVファイルでダウンロードできます。こうしたデータをサクッとローカル環境で確認したいなと思っていたので、ローカル環境で無料で使えるGeolonia Maps上にかんたんに表示できるツールを作ってみました。

» https://github.com/champierre/glnmaps

各プラットフォームで動くバイナリを用意できるよう、Denoで開発しました。

glnmaps(Geo*LoN*ia Maps) とは？

glnmaps(GeoLoNia Maps)は、各自治体が公開しているCSV形式のオープンデータをブラウザの地図上で確認できるツールです。 技術的な知識がなくても、誰でも簡単に使える平易なツールをめざしています。 ソースは1個のHTMLファイルとしてダウンロードできるので、それをホスティングして公開することも簡単です。

使用しているGeolonia Mapsは、https://.test 及び、http://127.0.0.1:<ポート番号> や http://localhost:<ポート番号> などのローカル環境で使用した場合や、GitHub Pages（https://.github.io）上では無料で使用できるので、開発やオープンソースのプロジェクトで利用することができます。

参考: Geolonia Mapsの開発環境での利用について

使い方

1. オープンデータとして公開されているCSVファイルを用意

各自治体のホームページなどで公開されているオープンデータのCSVファイルをダウンロードします。データカタログ横断検索システムで探すのも用意でしょう。

サンプルとして東京都調布市が公開している公共施設のデータセットを用意しておきました。

東京都 調布市 公共施設 データセット

※ オープンデータを管理するにはdimを使うと便利です。サンプルのdim.jsonをダウンロードして、

dim install

と実行すれば上記サンプルを含めたデータセットを簡単に用意できます。

参考: そろそろオープンデータを無秩序に管理するのは卒業したいので📦データを管理するパッケージマネージャを開発した【ツール開発】

2. glnmapsを使って地図に表示

glnmaps <CSVファイルのパス>

を実行するだけです。

glnmaps is running. Access it at: http://localhost:3000/

というメッセージが表示されたら、ブラウザを開き http://localhost:3000/ にアクセスしてください。

3. ソースをダウンロード

「ソースをダウンロード」のリンクをクリックすると、ソースのファイル(index.html)をダウンロードすることができます。

Chromeの拡張機能「Web Server for Chrome」などを使い、ローカルのWebサーバーでアクセスできるようにしたり、ホスティングサーバーに配置して公開することもできます。

インストール

1. glnmapsのバイナリをダウンロード

aarch64-apple-darwin

curl -L https://champierre.github.io/glnmaps/binaries/aarch64-apple-darwin-glnmaps -o /usr/local/bin/glnmaps

x86_64-apple-darwin

curl -L https://champierre.github.io/glnmaps/binaries/x86_64-apple-darwin-glnmaps -o /usr/local/bin/glnmaps

x86_64-pc-windows-msvc

curl -L https://champierre.github.io/glnmaps/binaries/x86_64-pc-windows-msvc-glnmaps -o /usr/local/bin/glnmaps

x86_64-unknown-linux-gnu

curl -L https://champierre.github.io/glnmaps/binaries/x86_64-unknown-linux-gnu-glnmaps -o /usr/local/bin/glnmaps

2. 実行できるようにアクセス権を変更

chmod a+x /usr/local/bin/glmaps

友人からこんな依頼を受けました。

20歳の自分に人生のアドバイスができるとしたら、どんなメッセージを送りますか？

という質問に答えてくれ、と。

キャリアコンサルティング論の講義のために参考にしたいということなので、想定されている回答とは違いそうなのだが、まっさきに頭に思い浮かんだのは、

若いときに、将来の自分から借金してでも、モノとかではなく体験とかにもっとお金を使うべきだった

ということ。ちょうど2月くらいに以下のように思ったのでした。

今でも後悔しているのは、卒業旅行でカナダにスキーをしに行ったのだが、その時ヘリスキーのツアーの確か3万円くらいする料金に学生ゆえしぶってやらなかったのだが、何でやらなかったんだろうって思う。もはや衰えた今の体力でできるかどうかはわからないので、そういう機会は掴めるときに掴むべき

— 石原淳也(Junya Ishihara) (@jishiha) February 15, 2021

詳しくは、将来の自分は今より稼いでいるという想定で、若いときには体験にお金をもっと使うべきと主張する、下記の DIE WITH ZERO という本に書いてあります。