我家の庭には芝を植えているんですが、たいした手入れをしているわけでもないので。。。

ちょっと分かりづらいですが、芝に雑草がはびこっています。。。

前はスギナが結構多かったのですが、最近はカタバミ（クローバーっぽいの）が勢力を伸ばしています。

このカタバミが厄介で、薄く広がっていくんですよね。。
今年の夏、子供にも手伝ってもらいながら一度結構きれいに除去したのですが、当然のように復活しています。

なんなら、他の雑草を抜いたせいで更に勢力を拡大しているかのよう。。

というわけで、これまで手を伸ばしてこなかった除草剤散布に挑戦してみようと重い腰を上げました

用意したのは写真にあるように噴霧器とMCPP溶液です

スギナ中心だったり、イネ科雑草中心だったりすると選択肢はちょっと変わってくるんだろうけど、カタバミで検索したらこれがヒットしたので、まずはこのMCPPにかけてみることに。

噴霧器は電池式のものも悩んだけど、蓄圧式でも大丈夫だろうと想像。
容量は、それほど大きい庭でもないので一番小さい2.5リットルのものを選びました

感想

結果はまだわかりませんが、使ってみた感想。

まず、噴霧器に関しては蓄圧式で特に問題はなかったけど、容量に関してはもう少し大きくても良かったかもしれないです。
まぁ、溶液を作ればいいだけなんですけどね。

溶液に関しては、規定量としては200倍稀釈なので2リットルの水に10ミリリットル。ただ、これをタンクに入れるのには注ぎ口がちゃんとしているバケツだったり、ろうとがあったほうがいいと感じました。
めっちゃこぼれてしまった。。。

一応、芝にも大丈夫という除草剤ではあるけど、庭には他にも玉竜やらハーブやらがあったりするので、それに対しての影響もちょっと気になる。
また、芝自体にも少なからず影響が出てしまうんじゃないかな？と心配はつきません。

ただ、これによって雑草取りの手間やきれいな庭が手に入るのであれば。。。というところですね。

どれくらいで効果が出てくるんだろうな～。楽しみです。

というわけで、9月は結構しっかりと走ることが出来たかな？という距離感。

しかし、見てわかる通りコンスタントに走っていたけれど、長距離が走ることが出来ていないんですよね。

アクアラインマラソンまで1ヶ月ちょっと。。。

不安で仕方がありません。

いつの間にか、NRCアプリにプランと言う項目が追加されていたのでマラソン向けのメニューに登録してこなすことにしました。

本来であれば、もっと前からこれに登録できていれば違ったかもしれませんが、今更です。信じるしかありません。

スピードランは、これまで取り組んでこなかったので、改めてやってみて大切なんだろうな、ということを感じています。
ただ、音声ガイドがマラソンメニューのスピードラン向けには用意されておらず、自分で時間を測りながらやるしかないのが辛いところでした。
単純に自分のやり方が悪いだけなのかもしれませんが。。

これまで、なんとなく走っているだけだった状態から、トレーニングメニューという位置づけで走るという形に変わるだけでも、ちょっと気持ち的に安心します。
少なくとも、今回ダメでもこれを続けていればフルマラソン走れるだろうと。

一方で、平日に60分とか走る時間を作ろうとすると結構大変です。

私は朝走っていますが、走った後にシャワー浴びて準備して仕事の開始時間に間に合わせようとすると、どうしても子供たちの世話や見送りが中途半端になるんですよね。

とは言え、もう残りの時間もわずか。
ラストスパート。頑張ります。

今更ながら、長距離走る時用の栄養補給に買ってみました。効果あるのかな・・

クラウドファウンディングと言うと、CampFireなどいろいろなサイトがありますが、科学技術系に特化したクラウドファウンディングサイトとしてacademistというサイトがあります

academist
https://academist-cf.com/

以前、なにかのタイミングでサイトの事を知って、結構面白い取り組みだな、と思ったわけですよ。
その時に支援こそしなかった（したつもりになっていた？）ものの、登録はしていたので定期的にメールは届いていて、少額でもいいから支援をしてみようと物色していて、面白そうなものを見つけた

こういう考古学って、正直自分がやることは出来ないけど、ちょっとロマン的な感じで憧れます。

ものづくり系のクラウドファウンディングと異なり、学術系のクラウドファウンディングの場合、見返りはそれほど金銭的な価値はなく、レポートだったりZoomでの会話だったりするのでこちらは本当におまけですね。

支援すると言っても、本当に少額から開始出来るのはいいとして、この支援量で本当に支援の意味になっているんだろうか？という疑問が湧いてきてしまう。
このあたりはこういうもののクラウドファウンディングの難しさを感じますね。

ちょっと一点困っているのは、月額支援型プロジェクトに対しての金額変更方法がよくわからんのですよね。。。
ちょっと色々と分かりづらい気がする。。。

週末のご予定は？

キャンプですよ！キャンプ。
夏の思い出にと、８月に予定していたキャンプを台風が来るということで泣く泣く延期。キャンセル料を取られながらも、悲惨なキャンプになるよりは良いかと。。。
なかなかキャンプ場の予約が取れない中でようやく取った今週末！！

嫌がらせのように、台風が関東を直撃しそうです

今回の台風は、勢力的にはそれほど強くなさそう。

とは言え、完全に関東直撃コースではあるので、雨はしっかり降るんだろうなぁ
ただ、ここまでピンポイントでキャンプ予約したタイミングで連続台風となると、売られた喧嘩は買わなければいけないという謎の使命感が生まれてきているのも事実。

すでにレンタル品のキャンセル期限は過ぎてしまっているので、費用はもうかかる。
どうなるか・・・

明日、もう一日考えます・・・

今週は、マンガ最新刊が目白押し

腸よ鼻よの7巻

キングダム66巻

そしてシャングリラフロンティアの10巻

どれも面白いのですが、個人的な最近のHITは断然シャングリラフロンティアです

題材もそうですが、こういうバトル物は読んでいてワクワクしますね。
10巻は特に、1巻からの因縁の相手となるリュカオーンとの戦いということもあるし、様々な奥の手とも言える技が目白押し。

いや、なんというか、もういい歳なんですけど未だにこういったものを楽しめるというのは自分としてはいいな、と思います。

単純なギャグ漫画みたいなものは、だんだん読まなくなってしまっていますが、こういう熱くさせるマンガは、ホント、いいです。
いや、語彙力ないな。。。。

展開も早いので、これから先もどういった物語が続くのか、楽しみです
ほんと、少年漫画好きにはおすすめです

SecurityReportを読んだことで知った、snykというセキュリティプラットフォーム。
無料版もあるようなので、ちょこっと触ってみた

https://snyk.io/

凛々しいドーベルマンがトレードマークです。名前はPatch。

価格体系はこんな感じ。
ちょっと個人で使ってみるのであれば、Freeプランで十分なのではないかと思う。

何をセキュリティチェックやテストの対象とするのかは、結構選ぶことが出来る

基本的にはGithubなどのソース管理ツールを登録し、その中のプロジェクトを選ぶ形になると思う

せっかくなので試しに、過去にチュートリアル的に作って放置されているプロジェクトを対象に含めてみた

Code analysis ではミディアムが6件検知されているけど、問題はpackage.json。
作ってから放置されているので、そりゃ問題があるバージョンが定義されているんだろうな。

選択すると、何が問題かを教えてくれる。そこで「Fix this vulnerability」を選択する

一番下にある「Open a Fix PR」を押すと、自動でPRを作ってくれる。
ちなみに、出来ることと出来ないことはやっぱりあって、下の3つは自動では無理のようだ

expressのバージョンが変わったことがわかる。

無事に、驚異が取り除かれていることがわかります。

PRの作成まで自動でやってくれるのはいいですね。
あまり、この手のツールを使ったことがないので、snykが特別に優れているかどうか。比較という意味ではわかりませんが。。。

今回はCode analysis上は問題なかったですが、コード上での指摘も今度見てみたいですね。

自動検知設定

初回にGithubと関連付けた際に表示が出ていたのですが、snykでのチェックを自動的に走らせることが設定で出来ます

ここではGithubを選択した際の設定を表示しています。

例えば以下のような設定があります

• 対象とするリポジトリはパブリックのみか、プライベートも含めるか？
• インポートされたプロジェクトにセキュリティとライセンスの問題がないかどうか
• 新たな脆弱性や既知の脆弱性を検知した際に自動的にPRを作るか
• 脆弱性を修正するために、最新のベースイメージを使用するようにDockerfileを更新するPRを作るか

自動的に色々と検知してくれるのはいいのですが、そのたびにテストが走ることを考えると、それなりの規模で開発をされている方ではやはりFreeプランでは心もとないと思います。

最後に

これまで実際にセキュリティ系の製品を触っては来なかったので、なかなか新鮮ですね。
作って終わりというわけではなく、継続して開発していくことを考えると、このあたりの脆弱性を自動的に検知して知らせてくれるというのは心強いものです。

実際に、OSSを使わないなんてことは現実問題難しく、そのOSSが別のOSSを使っていて、更にその先で脆弱性が。。。なんて話はざらにありそうですし、それを「頑張って」で終わらせるのは厳しいものです。

製品全体を考えた際に、どのフェーズでどうやってこれら脆弱性に対する対抗策を整備していくのか。これからはしっかりと考えないといけませんね。

日本時間の9/15 PM 3:42 に無事、Ethereumの The Merge が完了しました

そもそもEthereumとは？

当初、私も混同してしまっていたのですが、Ethereumは仮想通貨のEthを指すのではなく、Blockchain上で動作するアプリケーションのプラットフォームのことを指します。

そういう話をすると、クラウドを思い浮かべてしまいますが、現状のクラウドは、あくまでクラウドベンダー。大手で言うところのAmazon提供のAWS。Google提供のGCP。そしてMicrosoftのAzureといったように、企業が提供している、いわゆる中央集権的な仕組みが取られています。

さらに、実サーバーとしてはリージョンだとかゾーンといったように、現実世界の国や地域の影響も受けてしまうというのが現状です。
中国なんてまさにそれ。

Ethereumが目指すところというのは、そういった企業や国・地域の影響から脱却した。真に制限のないプラットフォームの構築となります。

もちろん、プログラムを動作させるには現実世界のコンピュータが必要となりますが、特定のコンピュータに依存することなく、分散実行・検証を行い、情報を保存することで、非常に多くのコンピュータを使った一つの大きなプラットフォームを形成するようなイメージですね。

現状の課題

実行するプログラムのことをスマートコントラクトやdAppsと呼ぶことになりますが、利用者の増加に伴って当たり前の話ですが、処理速度が低下するという問題が発生しています。

また、ブロックチェーン上にブロックを追加する際、いわゆるマイニングという行為が発生し、これが電力需要を圧迫しているという指摘もあります。

それら以外も、スマートコントラクトをEthereum上で動作させるには、その処理量やデータ保存量によって、手数料がかかるのですが、この手数料がその時のEthereumチェーン上が混み合っているかによって大きく変動します。

色々ありますが、要するにこれ以上Ethereum上でスマートコントラクトを動かしたりしていくにはスケーラビリティが足りない状態なわけです。

そして、それを解決するべく様々なロードマップがあるのですが、一つの大きな節目となるのが今回実施された The Merge と呼ばれるアップデートです。

The Merge

一番の大きな変更は、これまでPoW（プルーフオブワーク）と呼ばれていた、いわゆるマイニング行為を行って早くより複雑な計算を行ったら報酬がもらえるという仕組みをやめたことだと考えています。

では、どうやってブロックの承認を行っていくのかというと、PoS（プルーフ・オブ・ステーク）という仕組みに切り替わります。
これは、PoWで膨大な計算を早く行ったものが勝利するというものから、よりEthを多く持っている人からブロックの承認者を選出するという仕組みです。

つまり、ブロックの承認者選出に対して、膨大な電力を必要としない仕組みとなるわけです。

これまで、マイニングを行っていた報酬として配られていたETHも、より多くステーキングした人に対しての報酬へと切り替わるとともに、新規の発行枚数は減る見込みです。

つまり、ETHの流入量が現在と比較すると減っていく形となるため、場合によってはETHの値段は上がるのではないか？と思います。

何はともあれ、今回の The Merge 後、ETHの価格もそうですが、ガス代やスケーラビリティの問題が想定通り解決されるのか？

これから楽しみですね

Twitterを物色していたら、こんなものを見かけた

📣 We’re excited to present our new 2022 Snyk State of Cloud Security report.
Download the free report to learn about complex cloud security risks & challenges that organizations face in 2022. ☁️

https://t.co/DKZ9VXq2Xu

— Snyk (@snyksec) September 13, 2022

把握していなかったのだけど、セキュリティプラットフォームを提供するsnyk（スニーク）という企業があり、そこが出しているセキュリティレポートということ。
レポートの中身としては、エンジニアやセキュリティの専門家に対してのリサーチを行った結果をまとめたようなものだ

早速ダウンロードして読んでみた。
簡単な登録で読むことが出来るので、興味がある人は手にとっていただければと思う。

クラウドにおけるリスクの代表

開発者目線でクラウドのリスクって何かな？と考えると、やはり情報漏洩だろうな、と思ったらやはりそのあたりだった。

data breach（データ侵害）, data leak（データ漏えい）、Environment intrusion（環境侵入）が多い。
もちろん、クラウドのダウンタイムも34%ということでリスクと言えばリスクだけど結局のところ対応しなければいけないリスクとしてはセキュリティなのだという。

もちろん、これは snyk というセキュリティプラットフォームを提供している企業が出しているレポートなので既定路線ではあるんだろうけど、考えなければ行けない大きなテーマであることには変わりない。

リスクへの対応

本レポートでは、それらセキュリティリスクに対応するためにIaC（infrastructure as code)を大きく取り上げている。

IaCはどちらかというと環境構築においての効率化的な側面のほうが開発者から見た場合には大きい。

初期の環境構築ではIaCで構築はするものの、実際に動かしていく中での追加変更は、クラウドコンソール上で設定変更していくスタイルだ。

レポートでは、それではダメなんだと。
問題への対応に関してもIaCを追従させていき、IaCに対してのチェックを行っていく必要性を掲げている。
そして、それに関しては、組織のポリシーに従った形であるかをチェックできるツールを使って監査・検査できるようにしていく必要があると。
更に、ポリシー自体もちゃんとコードで表すべきだと。

When security policies are expressed solely in human language and exist
in PDF documents, they might as well not exist at all

P.32 ALIGN AND AUTOMATE WITH POLICY AS CODE (PAC) より

思わず笑ってしまったのが上記、「ポリシーが人間の言葉でPDFとしておいてあるだけなんて、言ってしまえばなにもないのと同じじゃないか！」
うん、PDFなんて読まないよね。。。

IaCに関して

インフラの構築はだいぶ、コードによって管理できるようになっているのは間違いない。
クラウドの環境構築においてはもちろんのこと、Dockerやk8sなどのコンテナ環境に関しても基本は定義ベースで構築する形になってきている。

一方で、構築した後に手を加えることもよくあって、それは構築時のコードに反映されているだろうか？に関してはできているとは言えない場面もよくある。

特に、簡易的なクラウド構築に関してはなれないIaCでやるよりもクラウドコンソール上から実施したほうが早い気がするんだよね。

ぶっちゃけてしまうと、両方できなければいけないというのが答えになるんだろう。
ただ、その中でもIaCで環境を構築するということに慣れていき、そこに対してのチェックを行うことが出来るくらい知識が付けば、しばらくご飯は食べていけるのだろうと思った。

先日紹介した、技術書店で以下の本を購入してしまいました

https://techbookfest.org/product/7Pzm4nWMKg9iAuX9Vz8Cbh?productVariantID=99cwTnd0rHckbcCgQCKRTf

本書を読みながら、紹介されているGlideと言うのはなかなか面白そうだな、と。

もちろん、ローコードツール独特の融通の効かなさみたいなものはあるんだろうけど、サクッと作ってみるという点では面白そう。
とは言っても、何を題材にするのか？ということに関してがやはり問題になるわけなんだけど、色々考えた結果家庭菜園向けのアプリなんて面白いんじゃないだろうか？と思った。

解決したい課題

私自身が、かれこれ10年以上それなりの広さの場所を借りて家庭菜園をやっている。
本格的な農家と、私のような趣味で家庭菜園をしている人との大きな違いは、当たり前だけど常日頃から見ていることなんてできないということだ。

なので、どのタイミングで何をするのか？
また、収穫の目安となる日程はなにか？
というところが、ズボラな私はいつもわからなくなる

ということで、解決したい課題を列挙してみる

• なんの品種をいつ植えたのかの記録をしておきたい
• その品種によって、標準的な今後の作業を知りたい
  • 追肥の時期
  • 実が付き始める時期
  • 収穫時期

その野菜なりがどういうタイミングで追肥が必要となるかや、実が付き始めるのか？は、種販売の場合はよく、種袋の裏に書かれていたりする。

実ができてから、収穫が見込まれるまで何日とか。植え付けから何日とかとか。
その情報を、植え付け段階で記録をしておいて、実際に日付が来たら通知が来る。

対象とする野菜に対して、考えなければいけない害虫やその対策なんかもあるといいかもしれない。

スイカとかを育てると、いつが収穫タイミングなのかが本当にわからない。
実ができ始めてから何日みたいな形なので、そういった記録を、苗単位、実単位で記録することができればいいんじゃないだろうか。

場所や天候によって、実際のところの収穫タイミングとかは変わってくるだろうからそういった情報も参考にして補正をかけることができれば面白そうだ

最終的に、そういった情報をいろいろな人が入力してくれることで、なにか面白い分析ができやしないだろうか。

追加妄想機能

とは言っても、初期段階での入力には課題が残る。
まずは、種袋の後ろを。。。と言っても面倒くさいのだ。

これに関しては、商品情報ではあるのでどこかしらにDBなりAPIになっていないかを考えたいところだし、袋裏を写真にとって画像解析から持ってくることができないだろうか。。。

天気のデータに関してはアメダスがあるので、そちらから。
天気や気温からくる生育のズレなんてのは正直、今後の蓄積されていくデータに期待となってしまうだろうなぁ。

あくまで家庭菜園という規模感で考えるのであれば、そこまで大規模なデータは手に入らないだろうけど、そこにはそこなりの面白さもありそうだ。

妄想アーキテクチャ

データの入力口としては、Glideで作ってみる。
Glideで入力したデータは、スプレッドシートへ書かれることになる。

スプレッドシート上のデータに関しては、外部データに関してはGASを用いてAPI叩くなりスクレイピングしてくるなりしたい

さっき書いたような画像解析なんてのも面白そうだ

どこまでを何が担当するのか？などなど、考え出すと色々出てくるなー

こうやって考えるのって結構楽しいですよね