日本語が母国語ではない方々に、「これはジョークだ」と気づいて貰うためのTIPS 職場で、日本語が母国語ではない方々と一緒に仕事をすることが増えてきました。円滑なコミュニケーションのために、どうすれば伝わりやすいジョークを言うことが出来るか？と、考えて、日々のなかで蓄積されたノウハウをここにまとめます。個人的に、ツッコミよりボケのほうが難しいと感じます。
真顔でボケると気づいてもらえない 自分で言った冗談に、自分で大笑いする図々しさが必要。
「オヤジギャグ」はハードルが高い 「オヤジギャグ」のようなものはアメリカにもベトナムにもあるそうなので、概念として理解はしてもらえる。「オヤジギャグ」という言葉を知ってもらって、必要に応じてすかさず「それはオヤジギャグですね！」と差し込むのが有用そう。
相手の知っている日本語を把握して、ボケに使う 例えば、相手が「わさび」という単語を知っている場合、辛そうなものを食べていたら適当に「それはわさびですか？」などと言っておく。
気を取り直して、真面目に「それはトウガラシですか？」と聞くと、相手に「いいえ、チリペッパーです」と返されることもあります。
「なるほど。って、やっぱりトウガラシやないかーい！」という、行き場のないツッコミを入れるべきか悩みました。
今後もノウハウを溜めていきたいです。ボケたいので必死です。
Kafkaとは ナンジャラホイから始まったので調べました。
Kafka on Docker ざっくり概要を掴んだら Docker で試します。なんか local で試すの重そうだな、環境汚しそうだな・・と感じたら、とりあえず Docker で試せるか調べるとだいたいある。 リポジトリ: https://github.com/wurstmeister/kafka-docker
チュートリアル: http://wurstmeister.github.io/kafka-docker/
docker-compose.yml の書き換えなどが必要なので、本家をフォーク& clone して使うのが良さそう。 Kafka 完全に理解したｸﾏ-ʕ•ᴥ•ʔ
Django Girls https://djangogirls.org/
Python フレームワークである Django を題材に、女性や性的マイノリティーなどテクノロジーの知識習得に壁を感じる方々を対象にワークショップを開いている慈善団体です。
コロナ以前は月イチ開かれるハンズオンにて Teaching Assistant として参加していました。(コロナでしばらく活動がなかったのだけれども、)最近小さなもくもく会があったので参加してきました。
主に Django Girls チュートリアルのDjangoフォーム部分の翻訳作業をしました。
チュートリアルは何度かやっているけれども、「ここって結局何がしたいんだっけ？」というところや「ここの考え方はどう翻訳(意訳)したら伝わりやすい？」など、つど悩みながらだったので思いのほか時間がかかりました。他のスタッフの方に相談しながら最後まで進められました。
なぜやるのか Wantedly みたいやな！
実際、女性向けの開発コミュニティは結構存在している。PyLadies や Java女子部、Women Who Go Tokyo etc..
「スタッフとして参加したい」
と、強く思ったのは Django Girls で、その理由は
コミュニティの理念として門戸の広さを感じた 自分がやりたいことにちかいなぁと感じた というのが大きかったからかもしれない。
他のコミュニティは、ある程度の前提知識がある女性向けだなぁと感じたのだけれども、Django Girls では
「ファイルとディレクトリの違いって何？」
だとか
「ターミナルとは？」
とか
「PC の中の『仮想環境』という意味がどうしても納得できない」
だとかの、参加者ひとりひとりの疑問に向き合いながら、スタッフたちで説明を試みたり一緒に考えたりする。
地方に住む学生だった頃
「エンジニアになりたい」 という意思はあれど、上京を反対されたり、地方に未経験者OKのエンジニア求人が無かったりした。そして、エンジニアと交流できるようなコミュニティも見つけられなかった。
もし、当時の自分と同じような立場の学生や女性がいたら、そういった人たちの小さなきっかけになるようなコミュニティがあればなぁ・・
と、考えたときに、そのコミュニティ像に一番近いと感じたのが Django Girls でした。
女性や性的マイノリティーなどテクノロジーの知識習得に壁を感じる方々を救いたいのであれば、NPOだとか、未経験者向けのエンジニア養成学校のようなサービスも多くある。
ただ、個人的に、エンジニアの「習得した知識をコミュニティを通して共有していく」という文化がとても好きで、わたし自身も Django Girls に参加することでたくさん学ばせてもらって感謝しているので、その恩返しのつもりでスタッフとして貢献していけたら良いのかなぁと思いました。
色々と堅苦しく考えてしまいがちだけれども、肩の力を抜きつつコミュニティでの出会いを楽しみながら活動していきたいです。
Hugo の画像をどこで管理するかの検討 候補
Git Large File Storage (LFS) Git LFS で画像データなどを管理する際のイメージが湧いていないので調査して整理する
https://git-lfs.github.com/ AWS S3 きっかけ Hugo on Vercel で blog を投稿した際に、記事内でつかっている画像 image が build 時大量に up されていて build が重いので何とかしたいと思いました。そもそも バイナリデータを大量に git で管理したくないなぁということで、いくつか候補を挙げて調査してみることにしました。
候補1: Git Large File Storage (LFS) って何だろう Git で画像や動画のような大きなファイルを別サーバーに分けて管理する方法があるらしい？ということで、どういった構成でデータをもつことになるのかザックリ調べました。
文字で読んでもサッパリ分からんだったので図で整理しました。
ローカルで blog(Markdown) を編集して Github に push する push の直前に該当の画像ファイルなどは LFS API を通して Git Large File Storage にアップロード される (Github には画像のオブジェクトハッシュやファイルサイズなどのメタ情報のみ保存される) (text pointer から実体が紐付くイメージで構成図を書いたけど逆にややこしい図になっているな・・) Markdown で書かれた blog text と、Git Large File Storage が vercel に(たぶん)アップロードされる vercel 上で hugo の build によって html に変換される → その際に画像ファイルも都度アップロードされる〜〜〜 ここまで考えて「あれ？LFSで速度改善されないのでは？？」と、気づきました。気づいてよかったし、着手前にきちんと調査詰めて要件を満たしているか確認するの大事だなと思いました。
Contribute Anniversary 先日、初めて OSS に PR を出して merge され、晴れて contributor になれたため経緯を書いていきたいと思います。
該当 PR:
https://github.com/kubernetes-sigs/kubespray/pull/8224
経緯 ansible-playbook を実行したら「設定値が適切でないよ」と Error が出たので、Github で PR や issue を眺めて原因を探していました。見慣れたアイコンがあるなぁと思ったら、なんと職場の上司がそのソースコードに対して PR を出していて、わたしの Error 箇所である「適切ではない設定値」が merge されていました。
何よりもまず「わたしの上司コントリビューターなの？！」ということに驚きました。「Error 箇所を特定していたら上司を見つけたよ！すごい！」と、上司へ報告をしに行ったところ、上司は
「この設定で Error したの？もしバグだったら自分の修正が世界中のユーザーに迷惑をかけることになる・・どうしよう」
と落ち込んで(？)いて、確かにそうだな・・大変そう・・と思いながらも
「じゃあこの Error の原因調べるのお願いしますね」
と、丸投げして一週間くらい放置していました。
もし仮に修正が必要なバグがあったとしても、わたしじゃ恐らく原因を突き止められないしなぁという気持ちもありました。
何の音沙汰もなく一週間経ち
(世界中の人が使っているツールのはずなのに、わたし以外誰も何も文句を言ってこない。おかしい)
と、流石に上司のせいではなく、自分の環境が悪いのだろうなと思い調査してみることにしました。
該当箇所についてドキュメント内を調べたところ「設定値が適切でないよ」と警告が出ていた箇所とは、また別の設定値が出てきました。具体的には、上司が indentfirst=None と設定してたところは first=False と設定するように書かれていました。あれ？やっぱり上司は世界中の人に迷惑をかけているのかな？と不安になりながらも、それらパッケージのおおもとのソースコードを見てみることにしました。
すると、以下のことが分かりました。
現行バージョンでは indentfirst=None、新しいバージョンでは first=False と指定されている indentfirst=None は次期バージョンで Error になるため Warning である 現行バージョンでも first=False の設定を使うことができる つまり、わたしの環境のパッケージのバージョンが一つ飛び抜けて高くなっていて(requirement.txt で様々なパッケージの推奨バージョンは指定されていたのに、どんな構築をすればそうなるんだ？)それが原因で今回の Error が引き起こされていました。上司は世界中の人に迷惑をかけておらず、わたしが自分で掘った穴に勝手に落ちている状態でした。
パッケージのダウングレードをすれば大丈夫そうということが分かったので、これで調査を切り上げようかと思いましたが、上司の出した PR を参考にして少し頑張ればわたしも今回の内容で PR を出せるのでは？と気づきました。