最近、日々のインプットに対してアウトプットが追いついていない。
ここ数日で一番大きい出来事といえば、仕事で長年コンビを組んできた人間と、万已むを得ぬ事情で別れ別れになったことである。
これまでに築き上げてきた信頼関係などもあり、非常に惜しいことで、この1〜2週間はあまりの喪失感で低空飛行気味だった。
とりあえず近況をまとめてここに書く。
電子辞書を買った話
思うところあって電子辞書が欲しくなった。
友人からは、「今の時代、スマホがあるのに何故？」と訝られたが、僕にとって電子辞書はちょっと高価なハンドスピナーくらいの存在感であった。
要するに暇つぶしの手遊び用の玩具が欲しかっただけであり、そこに電子辞書というアイテムを使うこと自体への漠然とした憧れがたまたま重なったのかも知れない。
強いて言えば、僕は多忙になればなるほど言語表現が貧しくなる体質なので、ビジネスメールの品位と格調の底上げを図るためにも脳みそをチートできるツールの助けを借りてみたかった事情もある。
たとえば、なにかの誘いを断る際、「お金がないので……」という凡俗な言い方よりも「手元不如意のおりから……」と文語体で綴る方がお上品であろう。 ときに相手の意に沿わぬ事柄を文章化する際には、波風が立たぬよう「言葉を選んだ感」を演出するのも大人のテクである（何
そんなこんなで、俄然電子辞書が欲しくなった僕は家電量販店に足を運んだ。
ちなみに学生時代は SII 製のモノクロ液晶の電子辞書を愛用していた。 キーボードのタッチ感が快適で非常に気に入っていたが、現在、SII は電子辞書から撤退しており、ほぼ CASIO の EX-Word と SHARP の Brain の2択であった。
僕が Brain を選んだ理由
さて、もろもろ迷った末、最終的には SHARP 製 Brain の高校生モデルにした。
ネームバリューとデザインでは EX-Word に軍配が上がるのだが、Brain はキーボードをぐるっと裏返せるギミックが気に入った。 机の上に置いて使うだけでなく、手に持ってどこでも使いやすいという、ただそれだけで使い所が一気に増えるのだ。
さらに、Brain はかねてよりユーザビリティの悪さ（特に検索の遅さ）が指摘されていたが、'21年型では EX-Word と遜色ないくらいには改善がなされており、この時点でほぼ Brain に心が固まった。
僕が高校生モデルを選んだ理由
なぜ、社会人の僕が敢えて高校生向けのモデルを選んだか。
中学・高校生モデルも大学生・社会人向けモデルも筺体そのものに大きな違いはない。
大人向けだからといって特段プレミアムな素材でできているとかそういうわけでもなく、言ってしまえば収録コンテンツとカラーバリエーションがポイントとなってくる。
各モデルの収録コンテンツを比較した結果、個人的には大学生・社会人向けのモデルよりも高校生向けモデルの方に魅力を感じたことが購入の決め手となった。
社会人向けモデルは調べ物に特化している一方で、高校生モデルは教材としての色が強い印象を受けた。 少し前にお世話になった『英文法のトリセツ』3部作も全巻収録されているし、NHK の『リトル・チャロ』も収録されている。
個人的にはこういうキャッチーな教材の方が口に合うなぁと思った次第である。
このほか、書きたいことは色々あるが、ひとまず欲しかった物が手に入って満足である。 暇なときにいじり倒したい。
以上、電子辞書のお話は一旦おしまい。
Kubernetes は引き続きお勉強中
そういえば少し前に、Kubernetes をがんばる話を書いた。
果たしてあれからどうなったかというと、会社の砂場環境に先輩が構築してくれた Kubernetes クラスタに対して、kubectl コマンドを放つ日々を送っている。
マニフェストファイルをちょこっと書き直して、kubectl apply を叩き、何が起こるか観察することを繰り返しているだけなのだが、そのたびに思い通りに行ったり行かなかったりするので、書籍を参照したり Google 先生に訊いたりしつつ経験値を積み上げている。
時間は限られているものの、会社から金を貰って就業時間中にこういう勉強をさせて貰えるのは、我ながら良い身分だなーと感じる。
課題
さて、この砂場環境がちょっと曲者で、マスタノードもワーカーノードも一緒くたになって 1台のベアメタルサーバ（ 192.168.7.1 ）で動いている。
ワーカーノードには Apache と Jetty をそれぞれベースにした Pod が配置されており、それらが内部的に連携することで一つのシステムを成している。
そして、192.168.7.1 宛の通信は、ポート番号によって Apache と Jetty いずれに疎通させるかを振り分けたい、と言われている。
ところが Kubernetes では、一つの IP アドレスを複数のプロトコルで使用することができないという課題が立ちはだかった。
解決策
MetalLB と呼ばれるロードバランサを利用すると IP address sharing が可能になると知った。
Kubernetes does not currently allow multiprotocol LoadBalancer services. This would normally make it impossible to run services like DNS, because they have to listen on both TCP and UDP. To work around this limitation of Kubernetes with MetalLB, create two services (one for TCP, one for UDP), both with the same pod selector. Then, give them the same sharing key and spec.loadBalancerIP to colocate the TCP and UDP serving ports on the same IP address.
Service (type: Loadbalancer) のマニフェストに metallb.universe.tf/allow-shared-ip:"xxx" というアノテーションを付加する（"xxx"は任意の文字列）と、この "xxx" をキーにして複数のロードバランサの EXTERNAL-IP が共通化される。
ただ、設定をいじくり回して kubectl apply を叩いてもなぜか設定が反映されずEXTERNAL-IP が変わらないという事象に遭遇し、ここで数日ハマった。
仕方がないので、一度 kubectl delete で関係しそうなロードバランサを殺して、再度 kubectl apply したところ、無事設定変更が反映された。
習うより慣れろ的な感じで、3歩進んで2歩退がる毎日である。
ラズパイと AWS IoT Core
少し前に、ラズパイが AWS に繋がった話を書いた。
その直後、テクニカルライターの大澤文孝さん (@sour23) から『「TWELITE PAL」ではじめるクラウド電子工作―「クラウド」による処理が「つなぐ」だけでできる! (I・O BOOKS)』という本の存在を教えていただいた。 深謝。
AWS IoT Coreについては、「TWELITE PALではじめるクラウド電子工作」で、ちらっと触れてます。
— 大澤 文孝 (@sour23) April 10, 2021
もし良ければ、本屋でチラ見していただければ……。
（全体のうちの最後の章だけですが）。https://t.co/SDw44y33n0 pic.twitter.com/hypPNQIhpL
「TWELITE PAL」ではじめるクラウド電子工作―「クラウド」による処理が「つなぐ」だけでできる! (I・O BOOKS)
- 作者:文孝, 大澤
- 発売日: 2020/04/01
- メディア: 単行本
ちなみに、IoT Core を扱う最終章は、本全体のほぼ半分の分量を占めているので、実はかなり力の入ったテーマであることが窺える。
さて、MQTT でデータを収集するところまではとりあえずできたとして、AWS に集めたデータをなんとか加工して有効活用したいと考えるようになった。
そんなわけで最近は AWS Lambda を復習中である。
Lambda もこれはこれで深いテーマで、やり込むと底なし沼だと思っている。
ただ、入り口は軽いし、EventBridge (CloudWatch Events) や DynamoDB や S3 あたりと連携すると、わりかし短時間でかなり強力なモノづくり体験ができるので、機会があればいつかここに書きたい。
このほか色々書き残しておきたいことはあったが、そろそろ長くなってきたので一旦ここで筆を置く。 ではでは。
