TCP/IPの海を潜っていく

　いつのまにか月は流れて二月になっていた。私が手の中に収めている言葉たちはちりぢりになっていて、コードとして大気を漂っている。最近はVue.jsやJavaScriptの教材を書いていて、それがいくらかおもしろいかんじになっている。

　やっていくと教材作成の流れがわかってきた。はじめにつくりたいもののコードをガガっと書く。そしてそれから、構築する内容を細切れにしてつたえる。相手の理解度を想定し、知っていることは省き、知らないことは詳細に書く。説明するとなぜか自分の理解度が増す。そんな日もある。

　さいきんの仕事は機械図面をかきなぐりながらTCP/IPの海を潜っている。以前はバラし（かいた組立図から部品図に書き起こすこと）を自分でやっていたが、後輩に任せることにした。このくらいのボリュームなら大丈夫だろうと思っている。実際そうだった。素晴らしい。そうして私は通信ばかりやっている。

　異なるメーカーが出している二つのデバイスの通信を構成しようとやっきになっている。単純にケーブルをつなげるだけではだめだった。なぜ、なぜ、と繰り返すうちに、この世界の通信のあらましを垣間見ることになった。知っていると思うが、人類は通信を階層構造で切り分けていた。TCP/IPの区分では4つに別れている。私は装置のマニュアルに書かれている見知らぬ言葉を抜き出し、それらを階層構造のどこに位置するかをメモに書き留めていった。

　たとえばイーサーネットは最下層に位置する。01の信号をもっとわかりやすく意味づけしている。Ethernet/IPとイーサーネットは別物らしい。なんだそりゃ。IPアドレスやサブネットマスク、ゲートウェイは二番目の階層だ。windowsの黒い画面にいろいろ叩いて、それらのアドレスを理解したり、彼らがどこからきてどこへ向かうのかを学んでいた。わからん。TCP/UDPはその上。でもこの二つの装置はModbusやMCプロトコルというよくわからないプロトコルで動くらしい。余計わからん。

　IoTモジュールからSIMを通してなにやら意味不明な言葉が送られてきた。でも、いまはまだ言葉を理解する段階ではない。この言葉を定期的にあげて欲しいのだ。本当に彼らは通信ができているのか、お互いがお互いを理解し合えているのか。

　いや、理解など到底できるものではないのだ。自身の理解すら難しい。だからプロトコルがある。決まり事があるから理解していなくてもやっていける。「相手を尊重する」「理解する」だなんて、そんな軽く扱ってはいけない。だれも相手を知ることはできないし、私も私を知ることはできない。

Photo by Daniel Seßler on Unsplash

文章2021

　気がつけば2021年である。一体どんな未来にいるんだ私は。西暦についての印象が90年代で止まっていて、それ以降は日々の意識とは遠いところにあった。それだからこうして浮遊感のある実体としてただいたりもする。

　去年はいろいろやった気もする。オンラインイベントの登壇や、ウェブアプリケーションの製作や、IoTでちょっとしたものをつくったりもした。ただ、自分の生活が変わった！　ということはなかった。日々生きていた。今年は生活を変えたい。大きな不満があるわけではないが、もうちょっと自分のやりたいことをやりたいのだ。将来のありかたとか未来とかそんな大味なあれこれではなく、もっと実体に即した生活を変えたい。

　変えるには時間とお金の使い方を変えなければならない。もうちょっとアウトプット主体で生きていきたいな。

クワガタを温度管理で育てていく

　非常に短いsoracom advent calender2020 2日目である。

　こどもは昆虫が好きらしく、夏の間はカブトムシやらバッタやら、いろんなやつがいた。冬になりようやくいなくなったと思ったら、なんとクワガタの幼虫をもらってきた。おい。

　クワガタは菌糸瓶とよばれる瓶のなかで飼われている。カブトムシは腐葉土でよいが、クワガタは木の菌を食べるのだ。そうして温度管理が必要になった。だいたい5度から25度の間ならいいらしい。ラフだ。それでも玄関先で飼っているので気になる。

　soracom GPSユニットを使い温度を調べた。

　わりとよかった。

　おわり。

空白というかスペースというかそういう例外を持っていたい/具体と抽象

Photo by Katsiaryna Endruszkiewicz on Unsplash

　ひとつの業務が終わる間際になって、ぬとぬとと粘着質な問題が発生した。なるべくなら被害を最小限に抑えてことを済ませておきたかったが、正解ではなかった。私は見事に被弾し、目に見えないダメージが蓄積された。それでも問題は解消に向かいつつある。もう少しだ。

　twitterで珍獣(@mc_chinju)さんが「具体と抽象」という本を紹介していた。面白そうなので読むことにした。その名の通り、具体と抽象について書かれていた。

　著者は、わかりやすさ、つまり具体が増えている近年の現象を恐れていた。具体は急激な社会の変化に対して弱く、適応できないのだと。

　社会がひとつの性質のまま順調に進むとわかりやすさが増えてくる。書店の平積みのタイトルを眺めるといい。「xxなら〇〇しなさい！」「xxな人は〇〇をする！」そのようなものが多い。タイトルも長い。

　そういうわけで、抽象化を説明するという流れだった。

　抽象化とはなにか。私の言葉で表現するなら「複数の事象を共通する枠組みでまとめること」である。その枠組みは重複もするし、上流下流の概念もある。筆者は以下のような説明もしている。

抽象化とは複数の事象の間に法則を見つける「パターン認識」の能力ともいえます。身の回りのものにパターンを見つけ、それに名前をつけ、法則として複数場面に活用する。これが抽象化による人間の知能のすごさといってよいでしょう。

細谷 功. 具体と抽象 (Japanese Edition) (Kindle の位置No.246-249). Kindle 版.

　抽象化を身につければ、少ない枠組みで複数の場面へ適用することができる。応用が効くのだ。

　これはもしかしたら、プログラミング学習でも必要なことかもしれない。システムを構築するにあたり、実装したいいくつかの機能を考える。それらを共通化できないか、上位と下位でわけられないか、考える。そしてひたすらコードをうつ。

　考えるのが抽象化で、コードにするのはひたすら具体化である。こうしてコードを書く人は、抽象と具体を行き来しないといけない。

　ただ、この本で気になったのが、事象を数式一つで表現することの賛美だった。どういうわけか、人間は単純な式を求めがちである。世界の法則がごくごく単純なロジックにより固められていると望んでいる。抽象化の美学である。ただ、現状のところはそううまくはいってない。ニュートン力学が適用できるのは大きめのもののみ。小さいものには量子力学が適用できる。

　現在、これらを統合する枠組みをみんなですごい探している。いつか存在するのだろうか。

　単純にひとくくりにすればいいだけではない。例外も存在しうる。それを許容する空白というか、スペースというか、そういうものを自分の中に持っておきたい。

具体と抽象

Rubyでオリジナルプログラムをつくるための教材をつくった。

　以前に記事を書いてから非常に長い時間が経っていた。その間はいろいろなことがあったが、私は生きていた。夏だと思っていたがいつのまにか冬になっていたし、缶コーヒーは熱くなっていた。

　教材をつくった。これをやっていけばオリジナルプログラムがつくれるよ、というものだ。どうやら巷ではオリジナルポートフォリオが必要らしい。スクールの課題をそのままやっていくのではなく、自分だけの成果物がいるらしいのだ。けれどもどうやってつくればいいのだろう。あまり良い教材がなかった。だからつくった。

zenn.dev

　還元セールをおこなったりして、教材を8本売ることができた。嬉しかった。最初に買ってくれた人が、有名な人だったのでそれもよかった。

　ただ、これをどうやって拡販していけばいいのかが分からない。質を高める必要もあると思うが、プログラミングのロードマップとして組み込まれないと難しいかもしれない。

　それでもやっていこう。

　ブログは良いなあ。思ったことを素直に残せる場所があってよかった。