nmizo's

汗っかきおじさんが，眼鏡拭き用に買っているクリーナー。18枚110円。 iPhoneを除菌するのにAppleがオススメしているイソプロピルアルコールのものだった（あってるかな）。 https://support.apple.com/ja-jp/HT207123 小さいけど，iPhoneやiPad，PCのキーボードを拭くくらいには使える。画面も汚れない。 3月末に，100円ショップ(ダイソー)の店頭にたくさんあって，他のアルコール除菌製品と違って誰も目を向けていないみたいだったから，たくさん買っておけばよかったかな。 -- 

ガートナーが発行するレポートは勤務先で読むことができるけれど，利用についてはかなり厳しい制約が掛かっているので，気安く「こういうことが書かれていたよ」なんて引用したりすることはできない。ただ，たまに内容が公開されるものがあって，今回のはその一例。 英語タイトル: 「Magic Quadrant for Operational Database Management Systems」 https://www.gartner.com/doc/reprints?id=1-1V6RXOTB&ct=191015&st=sb 日本語タイトル: 「オペレーショナル・データベース管理システムのマジック・ クアドラント」 「オペレーショナルデータベース」というのは，たぶん，ガートナーの造語じゃないかと思うが，ざっくり書くと「業務系アプリケーションに使われるRDBMSと非RDBMSの両方」らしい。SI屋に縁があるものはだいたいこのカテゴリだろうから，ここんところはあまり深追いしないでおく。 内容的には，おおむね予想通り。 ・純OSSは，ガートナーが見ているマーケットシェアにはほとんど入ってこないが，まぁしょうがないよね。 ・OSS『由来』の商用サポート製品は，DBMS市場全体との比較では高成長。だが，クラウドプロバイダほどには高くなく，クラウドプロバイダ提供のOSS由来のサービスに脅かされている。 ・Oracle，IBMなどの独自製品は，DBMS市場全体の伸びを下回っている (シェアを落としている)。 このレポートに載ったのは次の12社。MongoDBが今回から外れたらしい。製品単位じゃなくて企業単位での評価となっている。 　- Alibaba Cloud 　- Amazon Web Services 　- DataStax 　- EnterpriseDB 　- Google 　- IBM 　- InterSystems 　- MarkLogic 　- Microsoft 　- Neo4j 　- Oracle 　- SAP -- 

半年の内に2回目のPython特集。日経NETWORKの読者は日常的にプログラミングをするエンジニア達では無いはずなので，編集側にかなり強い思いがあったのか，前回(2019年10月号)が意外なほど好評だったのかのどちらかだろう。 ■2019年10月号の特集:「試して納得！Pythonで学ぶサイバー攻撃の手口」 ・ネットワークエンジニアでもPythonを学ぶことは『必要だ』ということだ。少なくともシェルスクリプトをイジるのと同程度には使えた方がいい。 ・私も知らなかったのだけれど，ARPパケットやEthernetフレームも作れるんだね。 https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/NNW_backnumber/201910/ ■2020年2月号の特集: 「ここまで自動化できる ！Pythonでネットワーク管理」 Pythonを学んだ方がいい理由のダメ押し特集。2019年10月号の特集のPythonを使ったハッキングテクニックも興味深い内容だったが，今月号の方が同じスジで実用性は高い。内容的には基礎的なレベルだと思う。おそらくもっと高度なことまでカバーできるんじゃないだろうか。←「そう思うなら自分で手を動かして試してみろ」ということだろう。 https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/NNW_backnumber/202002/ --

新規に発行されるRFCの番号が8000番台になっていて，その8000番台も1年くらいで食い潰しそうな勢いだ。実は8年ほど前にも同じ様に「なんと6000番台後半だよ」と思ったのだった。 ところで，RFCの番号って，几帳面にきっちりと順番に使っているわけでは無い。大物RFCにはキリ番を使うことがある様だし（RFC 8200とか），規格のバージョンアップの際には旧番号から覚えやすいものにすることがある（RFC 822 → RFC 2822など）。 …ということは，ところどころ虫食い状態で空き番号がたくさんあるんじゃないかな？と，ふと思った。 RFCの一覧ページはこれ: 　 https://tools.ietf.org/rfc/ これを眺めると，ところどころに「Not Issued」となっている番号があるので，虫食いになっているのはたしかなようだ。無効化（Obsoletes）されたRFCもたくさんあるけれど，一度は使われた番号だから，これについては「使った」ということでいいだろう。 もう1つの一覧形式で，Mini-Indexページなるものがあった: 　 https://tools.ietf.org/rfc/mini-index ぱっと見で，虫食い状態がわかる。言い換えるとそれしかわからない。 上記のMini-IndexのHTMLを解析して，具体的にどれくらい虫食いなのかを調べて見た。単なる酔狂でしかないけれど。 結果（RFC 8754まで） 個数 RFC番号  735 8000番台  996 7000番台  973 6000番台  971 5000番台  973 4000番台  982 3000番台 1000 2000番台  995 1000番台  933 999番以下 こうしてみると，最初の999番までが一番大雑把だ。 RFC化の検討に入ったけど最終的に発行されないものもあるから，2000番台の様に完全に埋まることは珍しいと思う。そういう意味では，まぁまぁ，几帳面に番号割当てをしていると思っていいのだろう。 さて，RFC 10000に到達するまで残り約1250。そこに達するのは，だいたい4年ちょっと後の2024年頃だろうか。 【参考: カウントスクリプト】 : count.sh # https://tools.ietf.org/rfc/mini-index

日経NETWORK，2020年1月号の特集記事から。 https://tech.nikkeibp.co.jp/atcl/nxt/mag/nnw/18/NNW_backnumber/202001/ PoE (Power over Ethernet) の特集が良。PoEについては，一般の書籍がカバーしてくれていないので助かる。かなり詳細な点についても記述してくれていて，これは私にとっての“保存版”だな。詳細まで書かないと尺が足りなかったからかもしれないと邪推している。 以前にPoEについては調べたことがあって，その際には，オリジナルのPoEである IEEE 802.3af と，簡単に書くと電力アップした IEEE 802.3at (PoE+ または PoE Plus)の2種類だったが，2018年にさらに新しい IEEE 802.3bt (PoE++)が登場していたらしい。これは最大90Wの電力を供給可能とのことだが，LAN用の撚り対線で本当に大丈夫なのか？まぁ，大丈夫なようにいろいろと考慮がされているんだろうけれど。 IEEE 802.3bt-2018の規格文書を入手して，気がついたことがある。 IEEE 802.3af/atまでは，規格文書の中には「Power over Ehternet」という呼称が登場しなかった。面倒なことに「Power via MDI (Medium Dependent Interface)」と書かれていた。たしかにこの呼称の方が正確なのかもしれないが，それほどまでに「Ethernet」を規格に持ち込みたくなかったのだろうかと思ったものだ。 ところが，IEEE 802.3btで，ついにIEEEが折れた。規格文書のタイトルからして「Amendment 2: Physical Layer and Management Parameters for Power over Ethernet over 4 pairs」と，「Power over Ethernet」の呼称が公認となった。IEEE 802.3本体が20数年の時を経て「IEEE Standard for Ethernet」という名称になったことも背景にあるのだろう。とにかく，よかったよかった。 さて，次はゼヒ「WoL (Wake on LAN)」を期待。これも一般

日経NETWORK，2019年11月号から。 https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/NNW_backnumber/201911/ インターネットドメイン名にまつわるトラブルが頻発しているらしい。これは「Webサーバを乗っ取られて変なコンテンツをばら撒かれた」みたいな不正アクセスによる事件ではない。ほとんどが，ドメイン保有者の不注意によるものみたいだ。 Webサーバやメールサーバを用意するには技術力(技術者)が必要だけど，ドメイン名を取るのは技術の話じゃないからね。そのあたりも「不注意さ」に影響しているのかもしれない。 最近，特に話題になっているのが，使わなくなったドメイン名を手放した後に第三者が取得して利用する「ドロップキャッチ」と呼ばれる事象。「ドロップキャッチ」とカタカナで書くと，なんかズルいことをしているみたいな印象もある。けれど，これは本当は正規の手続きで取得することだから，不正行為じゃない。誰かを騙そうとしているなど不正目的で取得した場合は別だけど，不正目的を立証するのは簡単じゃないだろう。 ドメイン名を手放す時には，「後にその名称を誰かに使われることになっても大丈夫か？」と，一度考える必要がある。けれど，もう要らないって時は，そのドメイン名を使ったサービスは終わってたり消滅してたりするだろうし，誰が責任者かも怪しい状態になっている可能性が高いんじゃないかと思う。整理を押し付けられた誰かが「とにかく処分・整理」となっている気がするので，「一度考えてみるべき」なんて忠告は届かないだろう。 結局のところ，サービスを始めようとする際に，立ち上げようとしている人達が「ドメイン名を取得して将来に禍根を残さないか？」と考える必要があるのだろう。 InternetWeekで日本ネットワークイネイブラーの石田氏が「(ドメイン名の)ご利用は計画的に」という標語を毎年挙げているが，それに尽きる。 ( ※2020年2月，下記URLで資料が公開になった。 　 https://www.nic.ad.jp/ja/materials/iw/2019/proceedings/d3/ ) つい最近，ドメイン名関連で次の様な記事を見つけた。 https://www.gizmodo.jp/2020/02/f