バベッジノジャンキー

　どっかで聞いたフレーズばかりが耳にはりついていてとれない。という事象はままある。定刻通り走る列車にかかわらず明るさは増えていく。わたしは日差しのながさをかんがえた。日差しにながさはない。ながさ。

　18世紀にチャールズバベッジは階差エンジンをつくりあげ、計算の自動化に踏み出した。エンジンは階差をつかって、多項式を単純な加減演算に変換して処理をする。タッチパネルはなく、歯車に一面一面に数値が記載されている。回転によって数値は増減する。桁上がりもする。

経済や社会の仕組みが複雑になれば、計算の必要性もそれだけ増す。文明の進捗は計算回数に比例するというわけだが、これがすなわちシッカルト以来の計算機開発の背景である。

p83

　階差エンジンは完全となることなく、バベッジは死んだ。資金面の問題とかいろいろあったらしい。

　あれから結構な年月が経って、そのエンジンを復刻することになった。できたらしい。youtubeでみた。すごいうごく。

　計算機はバベッジ以降、ものすんごい発展を遂げている。電気のエネルギーで小型化とか、いろいろかのうになった。

　わたしたちはどこにいくのだろうね。

　フレデリックのジャンキーを聞いている。よい。

バベッジのコンピュータ (ちくまプリマーブックス)

ModbusTCPとマスクの化石/「 銃・病原菌・鉄（上）」

　結局、通信はうまくいった。塞がっていたポートをうまくよけた。PLCとIoTデバイスにおいて、互いのIPアドレスを知り、ポートを知り、プロコトルを理解させるのはそこまで難しくなかった。ただ、わたしの知識が足りなかっただけだった。それでもなんとかなった。クラウド側のプログラムもうまいこといったので、来週からうまく運用できそうだ。

　それはどうでもいいとして本を読んだ。「銃・病原菌・鉄」というやつ。ひどく昔に流行った気がする。最近活字を読んでなかった気がして、学生のころの記憶を探ったらこいつが出てきた。

　人類はなぜ地域間で差異が生まれたのか、を説明していた。結局は大陸の形が原因だった。ユーラシアは東西に広く、アメリカは南北に長かった。

　同じ緯度にある場所は、農作物の生育環境がある程度定まっていた、短期間で効率的な食料供給が可能となった。だからユーラシアはいい感じだった。けれどアメリカはいろんな環境になるから、その土地に合う作物が伝播するのが遅くなった。

　家畜の種類を増やせなかったのも痛い。家畜は労働力の足しになるだけでなく、病原菌の媒介となった。日常的に動物と接していると、飼い主は病原菌の抗体をもてた。だからヨーロッパの人々はインディアンに勝った。インディアンはこわい病気の抗体を持っていなかった。その名は。忘れた。

　ざーっと読んでわかる気になった。それで良かった。これらの要約はどこかに転がっているわけで、私が理解する必要はない。それにつけてもコロナは怖い。人類の進化とか繁栄にあたって、このコロナはそうとう大きい分岐点になりそう。

　ITの力で全世界はワールドワイドに展開された。もうどこでもフラットデザインである。しかし、コロナはそうならない。なぜか流行る国と流行らない国がある。ワクチンをもっているところ・マスクをしたところが強い。今後はそうなる。

　つぎに来るのは大地震かと思っていたらコロナだった。全人類はマスクの化石を生み出す。そうして一億年ほど経った先に、私たちの子孫はなにをかんがえるのだろうか。

「この時代の人々の記録はデジタル信号におきかえられており、復元は非常に難しい。われわれのようなDNA記録媒体は持ち合わせていないためだ」

知らない。

Photo by Caseen Kyle Registos on Unsplash

銃・病原菌・鉄　上巻

分かっちゃいるけど、やるのは難しい /「エッセンシャル思考」

　書き始めが冬のことばかりになっている気がして、私自身が寒さを求めているのだなと感じた。それくらい今年の冬は暖かい。始発の電車で会社に向かう時、冷えた手を缶コーヒーで温めたりもしたいが、そういうほどでもない。だから私はセブンカフェのコーヒーを買うのか。あれおいしいよね。関係ないね。

　エッセンシャル思考を読んだ。目標を明確に！余分なことはしない！そうすればOK！そういう本だ。「そんなのわかっているよ」という声も聞こえるが、これはただわかっているだけではダメだ。実践を伴って初めて価値が生まれる。本を読んで、少しずつエッセンシャルな形が身についてきたので、記録しておく。

　まずは本質的な目標を定める必要があった。これはワクワクして、具体的なものがいいらしい。私はひとまず「IoTで10万円稼ぎたい！」とした。次に不要なものを捨てることにした。この捨てるというのは難しいのだが、なにか新しいことを始めるなら、なにかを捨てなければならない。私は自分に降りかかる仕事のうち、後輩に任せられることは任せることにした。これで自分のやりたい本質的な仕事（社内IoT化）に集中することができた。

　なにも後輩に全部投げるわけではない。目標と期日は明確に伝えた。具体的な方法は後輩も知っていたので、あまり細かく注文するのはやめた。重要だったり、期日が短い仕事は進捗を細かく追う必要があるが、それも最低限にした。時々フォローはするが、いまのところ案外うまく回ってきている。彼も着実に成長しているのだ。すばらしい。私はIoTをやるぞ。

　仕事で身につけたIoTスキルを個人活動でも生かせるようにしたい。そのために職場の仕事はIoTだけになるように努力している。

　捨てることができてきたら、自分のパフォーマンスを高めることを考える。エッセンシャル思考では睡眠時間の確保をうたっている。私は少し睡眠時間が少なかったので、会社の昼休みに10分ほど寝るようにした。これはどう変わっているかよくわからない。ただ、健康に対する意識は変わった。今までは風邪をひいいたら治すくらいにしか考えていなかったが、今は風邪を引く前に体をコントロールするようにしていている。睡眠、運動、野菜、瞑想。瞑想はいらないか。

　あとはバッファをとる。ひたすらバッファをとる。予想してた時間の1.5倍をとるといい、と本に書いてあった。そういうわけで2,3日で終わりそうなことを1週間で行うような計画を立てた。やってみると、突発的な別のことがらや不具合がおこって、ほんとうに1.5倍の時間で収束することもあった。すごい。バッッファすごい。

　エッセンシャル思考は楽しい。楽しいことだけに集中して日々を過ごしていたい。

（Photo by Dan Meyers on Unsplash）

エッセンシャル思考 最少の時間で成果を最大にする

広く深く楽しいIoTの本 /IoTエンジニア養成読本 設計編

　難しく考え過ぎていた。雪は降らなかった。当たり前と思っていたことがそうではなかったりした。日々の暮らしにいくつかの句読点をうち、私はそれを読み進めていく。IoTが熟成していく。日本語もままならない。
　「IoTエンジニア養成読本　設計編」を読んだ。非常に養成された。ここまで広く深くIoTに言及している本はないのではないか。どこか皆IoTを未来っぽい技術だと思って、距離を置いて発言してるがこれはそうではなかった。IoT使われるデバイス、通信、クラウド、セキュリティ、それらが散りばめられている。自分の中でなんとなく頭に入っていた言葉たちが体系化されてきた。この感覚は久しぶりで興奮する。

　前にも書いたが、IoTは全ての知識を頭に入れておく必要はない。そして全ての技術を自分で開発する必要もない。大切なのは生産性の向上である。IoTをやって、自分や周りが豊かになればそれでいいのだ。お金をかけてもいいなら、既存の良いサービスを使ってしまおう。クラウドやデバイス、良いものはたくさんある。私がおすすめするのはM5Stack + soracom である。これでだいたいのデータは可視化できてしまう。機械学習やエッジコンピューティングとかをやろうと思ったらAWSやラズパイが入ってくるだろうが、それはまたそれの話。

　この本に書いてあることもやりながら学んでいけばいい。

　つまり、自分の得意な領域だけでなく、センサーからの情報取得方法、組み込みコンピューティング、ネットワークの設定、クラウド、判断のためのアルゴリズムや機械学習など、多岐にわたる知識と技術を一定レベルで習得しておけば、自らの手で新しい価値を生み出すことができる可能性ができるのです。

「IoTエンジニア養成読本　設計編」p150

　そうだね、そのとおり。

IoTとセキュリティ

　本書にも書かれていたが、IoTにはIoTならではのセキュリティ上のリスクがある。デバイスが小さく、マシンパワーが小さい。そして保守が困難な場合が多い。誰かがさーと持ち帰ってしまうかもしれないし、デバイスに複雑な暗号処理をさせるようなことは難しい。どうするか。

　経済産業省がIoTセキュリティガイドラインを発表している。
IoTセキュリティガイドラインを策定しました（METI/経済産業省）

　これをふまえて、セキュリティを色々考えていくといい。社内の啓蒙や、ロギング、リリース後の保守などさまざまなことが書かれている。

　ざっくりと本を紹介した。楽しい本だった。今後もざっくり本の感想を書いていくぞ。

Photo by brandon siu on Unsplash

IoTエンジニア養成読本 設計編 (Software Design plusシリーズ)

機械設計とプログラミングはちょっと似てる/「リーダーブルコード」

　加工機の切削音が私の体を揺らしていた。六軸のロボットたちは今日もげんきに部品を振り回して、それぞれにセットしている。ブロワとときどきのアラーム音。私はここで生きている。あるいは文章を補給しなければならなかった。自身の中の言葉はとうの昔に枯渇していて、私はだれかのセリフをそのまま伝えるだけのテープになった。ここでメモを書こう。

　リーダブルコードを読んだ。より良いコードを書くためのテクニック、とうたっているだけあって、いろいろと優れていた。共感したのは「優れたコードは理解しやすいコードである」ということだ。たしかにそうだった。コードは機械だけではなく、人も読むものである。なにかを共同でつくるとき、保守するとき、コードは自分以外の人に読まれる。そのときに理解に時間がかかってしまうものではダメなのだ。自分以外の人とは数ヶ月後の自分も含まれる。

　後半の章は、わたしのレベルではまだまだ活用できそうにないが、前半のものはすぐに適用できそうだ。変数名や関数名をもっとわかりやすいものにしたり、コメントをつけることだ。類語辞典を使って、もっと明確な意味がないか探すというのは「なるほど！」と思った。

　本書が述べている「優れたコード」の価値観は、機械設計でも適用できる。図面をかくときも、わかりやすいものでなければダメだ。寸法の抜けがあったり、基準面が一致していなかったり、加工の実現性のないものをかいてはダメだ。

　ただ、もっとも優れた機械設計というのは設計しないことだ。わたしたち技術者はの仕事は、技術的な問題を解決することだ。図面をかくのが仕事ではない。設計せずに問題が解決できるならこんなに素晴らしいことはない。購入品で済ませる、ありもので済ませる。これらのことを考え抜いて、それでもだめなら設計する。きっと、コードをかくときも、こんなイメージでいいのではないか。

　リーダブルコードの全てを理解してつかいこなすのはまだまだ時間がかかりそうだ。けれども、手元にはあったほうがいい。わからないことがあったら、少しずつこれで調べていこう。

Photo by Tedward Quinn on Unsplash

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)