僕は発展途上技術者

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.

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

JavaScriptとRubyとで配列内の目的のオブジェクトの前後を取得する

クイズです。

配列内の特定のオブジェクトの次(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 を振り返ります。

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

Keep(来年も続けたいこと)

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

Problem(問題点)

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

Try(来年改善したいこと、やってみたいこと)

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

ChatGPTによるGeoJSONの作成から修正まで:実体験からの感想

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

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

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

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

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

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

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

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

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

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

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

いまさら Lirbon を紹介する

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

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

Libronの使い方

この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 で公開しており、見る人が見れば、この中で不正なことをしているかどうかはわかるようになっている。

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

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

自宅は集合住宅で、はじめから各部屋に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 などストリーミングサービスを観ているとき、たまに切れることがこれまではあったので、それが少なくなることに期待したい。

CSV形式のオープンデータをブラウザの地図上でかんたんに確認できるglnmapsというツールを作りました

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/ にアクセスしてください。

glnmaps.gif

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

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

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

web_server_for_chrome.gif

インストール

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歳の自分に人生のアドバイスができるとしたら、どんなメッセージを送りますか?

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

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

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

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

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

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

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

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

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

↓「キラーン!」シールについて知らない方はこちら

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

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

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

↓リンク先をクリックしたら、緑の旗ボタンを押してください。

https://xcratch.github.io/editor/#https://champierre.github.io/posenet2scratch/kashikokunaru.sb3

プロフィール

株式会社まちクエスト代表、つくる社LLC代表。

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

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

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

Email: webmaster at champierre dot com

Twitter @jishiha

最近のエントリー

アーカイブ