Working as a programmer (Rubyist) in an international environment while living in Tokyo

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.


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 行き来しているとはまるな、これ。

モノリス vs マイクロサービス


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

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

Scratch Day in Tokyo 2023 Show & Tell 振り返り

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



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


  • 動画で配信する旨を直前に登壇者に伝えることとなってしまい、一部の作品でタイトルやクレジットの表記の調整をお願いすることになったり、配信内容を調整する必要が生じてしまった。
  • これまで応募者がどんな人であるかということは全く問わず、基本的に応募作品はすべて採用という方針を取ってきて、例年様々な年齢、男女の作品が発表される結果となってきてはいたのですが、今年は確かにかたよりがあると思いました。
  • 年々作品のレベルが上がってきており、前回開催から4年が空いてますますプロ顔負けの作品が多くみられたのですが、そうなってくるとまだ Scratch をはじめてまだ少しなんだけど、といったこどもたちの発表がしづらい雰囲気になってしまっている気がする。


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




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

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

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







いまさら Lirbon を紹介する

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






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



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




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


IPv6 パススルー有効かどうかの見分け方


このほど、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


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

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

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

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


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



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

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

dim install


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

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

glnmaps <CSVファイルのパス>


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

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


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


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



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


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


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


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


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








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

PoseNet2Scratch を使っていつでもどこでも「キラーン!」と賢くなる

MakerFaire 2020 ではやっていた「キラーン!」シール。


メイカーフェアで来場者を賢くした :: デイリーポータルZ

僕はもらいそびれてしまって悔しかったので、身体の各部分の座標を取得できるScratchの拡張機能 PoseNet2Scratch を使って作ってみました。これでどこでもいつでも賢くなれます。RubyKaigi に向かう途中、作ったので新幹線の中でキラーン!

この機会に PoseNet2Scratch を Xcratch に対応させたので、以下のリンク先より、誰でも賢くなれます。キラーンのサイズや位置は適宜直してください。





Scratchで楽しく学ぶ アート&サイエンスRaspberry Piではじめる どきどきプログラミングを書きました。

オンラインコンテンツ: 大人のためのScratch

Amazonから図書館検索 Libron、iPhoneアプリ ひらがなゲーム かなぶん を作っています。

Email: webmaster at champierre dot com

Twitter @jishiha