nmizo's

出版元Webページ: https://gihyo.jp/book/2019/978-4-297-10623-2 執筆陣によるサポートページ（GitHub）: https://github.com/neko9laboratories/tcp-book ■総論(総合所見)として 「TCP/IP」ではない。「TCP」だけに完全に特化した本だ。 おもしろかった。後半の詳細部分には目を通しはしたが，かなりの流し読み／ナナメ読みだったけれど。 これは入門書ではない。タイトルには「入門」と付いているが絶対に違う。 でも，書籍という形にまとめて出版する価値は十分にある内容。 でも，大学の専門課程で担当教授が指定する教科書じゃないし，どれだけの人がこの本を購入してくれるのか，とても心配。 マーケティング的にもそんな心配をしたかもしれない。だからこそ書名に「入門」を付けたのだろうか。いや，それじゃあ欺いたことになっちゃうから，もしかしたら本当にこの内容が「入門」だと思ってたんだろうか。 ■OSS視点から… 本書はTCP特化ではあるが，TCP/IPというプロトコルは規約(インタフェース)も，設計(アルゴリズム)も，実装(プログラム)も，ほとんどすべてがオープンな状態で発展してきた。TCPの輻輳制御という，とてもニッチな世界でも同様だと言うことがよくわかる。性能だけではなくて，相互運用性(Interoperability)の良否も，新しく登場した技術の優劣に影響している。 なぜオープンにするのか？ (ねらい，もう的は何か？) (ねらいや目的のためには) 何を／どこをオープンにすべきか？ それらのオープン性を維持して，どのように維持，発展させるか？ などを考えさせられる。 -- 

汗っかきおじさんが，眼鏡拭き用に買っているクリーナー。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 #...

日経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...

ちょっと前にサワリを書いた記事: 「Wi-Fi 6 と IEEE 802.11ax の関係がモヤモヤ」 ( https://nmizos.blogspot.com/2020/02/wifi6-and-ieee80211ax.html ) の続き: IEEE 802.11は無線LANの国際規格。無印(？)から始まって，802.11a，b，g，n，ac，ax と，規格化の事情を知らなかったらワケがわからんだろう。さらに，adやayだってあるぞ。たぶん，みんな「ワケがわからん」と思っていることだろう。801.11の数字部分だけでも意味不明なのに，n → ac → ax と尻尾のアルファベットがさらに意味不明(※a)。そこに救世主登場。Wi-Fi 4，Wi-Fi 5，Wi-Fi 6 とシリアルなわかりやすい番号で呼ぶことにしようよ，と。うむ。考え方というか，ねらいとしては大賛成。標準化機関の規格番号を，一般消費者が知っている必要性なんかまったく無い。 けどね…。ちょっと釈然としない面も残っている。 「Wi-Fi」ってWi-Fiアライアンスが認証した機器に付ける“ブランド”じゃ無かったのか？ 本当に Wi-Fi 6 ＝ IEEE 802.11ax なのか？ 一般のIT系ニュース記事でも，このあたりの区別はできていないようだ。 Wi-Fiアライアンスの発表以来どうもモヤモヤしていたのだけれど，公開文書『Generational Wi-Fi User Guide』( https://www.wi-fi.org/ja/discover-wi-fi からリンクしている)(※c)を見つけて，ようやく，一応は理解できた。でもスッキリはしていないで，モヤモヤしたままだ。 ◆ちょっと乱暴な結論 わかったことを簡潔に記すと，つまりこういうことだ。 　 Wi-Fi 6 ≒ IEEE 802.11ax 　　　　　　　　…(1) 　 Wi-Fi CERTIFIED 6 ≠ IEEE 802.11ax 　　…(2) 　∴　 Wi-Fi 6 ≠ Wi-Fi CERTIFIED 6  　　　　…(3) たぶんWi-Fiアライアンスは明言はしないと思うが，割り切って(3)を許容しちゃったところが今回の発表のおもしろくて怪しい点だろう。 ◆解...

クリエイティブな者は周囲に影響を与えるものの，組織が閉鎖的だとプラスの影響ではないかもしれないという。ちょっとショッキングな結果の様な気もするし，少し考えてみると，ありがちなこととも思える(思いつくことがある)。開放的なネットワーク構造を取っていないと，せっかくの宝が毒を出してしまうということか。 いわゆるビジネス書みたいな根拠の怪しい啓蒙メッセージではなくて，学術的・科学的な調査結果に裏付けられている点が興味深い。 「ヴォイニッチの科学書」(有料Podcast)，2020/2/1配信より https://audiobook.jp/podcast/3 後日，おびおブログにも掲載された: http://obio.blog.fc2.com/blog-entry-1851.html 『　情報共有ネットワークの開放性が低い場合には、創造性の高い情報共有者は対象者のイノベーションにネガティブに影響してしまうことが明らかとなりました。　』 -- 

「そんない理科の時間B」という，素人にもわかりやすいサイエンス系ポッドキャスト。今般の新型コロナウイルスを受けて用意されたコンテンツ。 東京大学，2008年の「学術俯瞰講義」の一部。ウイルスの説明のためのものでは無く，最先端の薬学？分子生物学？の一端を紹介する一部分として。 　↓↓↓ 「第348回 ベテルギウスとウィルスの基礎」 byそんない理科の時間B @sonnaip https://sonnai.com/rika/%e3%80%8c%e7%ac%ac348%e5%9b%9e-%e3%83%99%e3%83%86%e3%83%ab%e3%82%ae%e3%82%a6%e3%82%b9%e3%81%a8%e3%82%a6%e3%82%a3%e3%83%ab%e3%82%b9%e3%81%ae%e5%9f%ba%e7%a4%8e%e3%80%8d-by%e3%81%9d%e3%82%93%e3%81%aa.html 学術俯瞰講義2008 --- 137億年の「物質」の旅―ビッグバンからみどりの地球へ― の“柴崎 正勝「物質の創成」”の 第8回(4)あたり https://ocw.u-tokyo.ac.jp/course_11312/ --

Wi-Fiアライアンスが無線LANの呼称を「Wi-Fi 4 ／ Wi-Fi 5 ／ Wi-Fi 6 とかにしようよ」と提案。おおむね好感されている様子だし，私も賛成。 でもね，なんか怪しいというか，スッキリしないというか，モヤモヤ感が残るので，このあたりのことについて徐々に調べつつある。今回はその中間報告。でも，だいたいの大筋は見えたように思う。 ◆Wi-Fi 6にまつわる疑問 《疑問 1》「Wi-Fi」ってWi-Fiアライアンスが認証した機器に付ける“ブランド”じゃ無かったの？ 《疑問 2》「Wi-Fi 6 とは IEEE 802.11ax のこと」は本当なの？ ◆《疑問 1》について: Wi-Fi 4／Wi-Fi 5／Wi-Fi 6 は自由に使って大丈夫。Wi-Fiアライアンスは，これらの呼称をアライアンス会員じゃなくても広く使うことを認めている。 ◆《疑問 2》について 「Wi-Fi 6 ≒ IEEE 802.11ax」と言って良さそうだ。IEEE 802.11n，IEEE 802.11ac，IEEE 802.11ax，といったIEEEの規格番号が「使いにくい」のを解消するのを意図したものだから。ここで，「＝」じゃなくて「≒」としたのには理由があるが，これについては面倒くさいので割愛する。「Wi-Fi 6に対応している」と言った場合には「IEEE 802.11axに対応している」ことを意味するのは間違いない。(論理に敏感な方はこの言い回しでだいたい想像してもらえると思う)。 ◆しかし新たな問題が… ところで「Wi-Fi CERTIFIED 6」というのもある。これこそがWi-Fiアライアンスの真骨頂というか，認証プログラムに合格した製品が名乗ることができる「お墨付き」。 Wi-Fi CERTIFIED 6は認証を通ったかどうかを示すもので，中身がWi-Fi 6 (≒IEEE 802.11ax) であれば良かったのだけれど，話はそう簡単じゃ無い。 Wi-Fi CERTIFIED 6の要件には，IEEE 802.11axに含まれない事項も含まれている(たとえばWPA3など)。 つまり， 　『 Wi-Fi CERTIFIED 6 ≠ IEEE 802.11ax 』。 したがって(ちょっと雑だが)， 　『 W...

OSSコンソーシアムのメンバとして， オープンソースカンファレンス2020 Osaka に参加した（1月24日・25日）。セミナーの部はデータベース部会（DB部会）が入門セミナーを実施，ブース出展ではAI IoT Robotics Automotive部会（AIR部会）のドローンを使った実証実験の様子を披露。 OSSデータベースの入門セミナーは， オープンソースビジネス推進協議会（OBCI） との共同企画として2枠連続で実施。二大OSSデータベースのMySQLとPostgreSQLの入門レクチャーが両方まとめて聞けるのがウケた（よかった）のか，50人近くの聴講者に集まってくれた。 このセミナーの開催報告は，技術評論社のIT情報サイト gihyo.jp の 「OSSデータベース取り取り時報」第54回（2020年2月号） に掲載。 発表資料OSSコンソーシアムのページからダウンロード可能 。 -- 

以前書いたブログへのつづきシリーズ (ちょっと安直に…): 「2つの白書 〜 情報サービス産業白書(JISA)、IT人材白書(IPA)」 https://nmizos.blogspot.com/2019/09/whitepaper-ipa-and-jisa.html

毎月連載の「OSSデータベース取り取り時報」 に載らなかった／載せなかったネタをメモしておきます。今回は 第52号(2019年12月号) からこぼれたものです。主に私が担当しているPostgreSQL関連が中心です。 ◆ PostgreSQLカンファレンス2019のtogetter https://togetter.com/li/1431055 記事には出来ない率直なコメントとかもたくさんあっておもしろい。 ◆ PostgreSQLの拡張性の課題を解決する「Azure Database for PostgreSQL - Hyperscale (Citus)」――MicrosoftがAzureマネージドサービスで提供する理由 https://www.atmarkit.co.jp/ait/articles/1911/06/news003.html MSはこのCitusに結構力を入れてプロモーションしている印象があるけど，SQL Serverとどう棲み分けるつもりなんだろうかと，余計な心配をしてしまう。 ◆ PostgreSQLとMongoDBが増加 - 11月データベース人気ランキング https://news.mynavi.jp/article/20191105-918885/index.html 「トップ3と4位の間には大きな差があるが、4位と5位のPostgreSQLとMongoDBは長期にわたってスコアの増加を続けている」という，いつも定番の解説。 ◆ オープンソースデータベースの現状--複数のデータベース利用、クラウド、ライセンス https://japan.zdnet.com/article/35143492/ 是非読んでみてください。 -- 

http://www.jp.ipv6forum.com/ https://twitter.com/InternetWeek_jp/status/1198857910438121474?s=20 【私的な概要】 ・例年，InternetWeekと併せて開催されるシンポジウム。 ・World IPv6 Day / World IPv6 Launch とかが開催された2011〜2012年ころはIPv6関連の情報を得る機会は多かったが，昨今はそういう機会がめっきり減っている。InternetWeek本体のIPv6セッションとこのシンポジウムは，アップデート情報を得る貴重な場になっている。 【私的な総論】 ・ただ，今年はとくに“明るい話題”が少ない年。 ・足まわりとしてのNWのIPv6対応が一段落したが，普及は足踏み状態。 いくつか，“拾い物”だった話もあった。 ・IETFでは規格の改定の議論が進行中。RFC 8200で固ったというわけではなさそう。取り上げられてたのは，拡張ヘッダの制約とSRv6の関係。ただ，もっと他にもあるんだろうか。JPNICがマメにレポートしてくれているIETFニュースを注視しておいた方がよいかもしれない。 ・APNIC発表の，各国のIPv6普及状況と，時系列データからわかる“事件”の影響(〇〇〇製機器の証明書問題の際にIPv6トラフィックが目に見えて減った国がいくつかあった)。 ・IPv6普及・推進高度化協議会がIPv6の認定試験を検討中らしいが，本当か？ イベント的な観点からおもしろいのは，やはりパネルディスカッション。 ・でも，大胆過ぎてもいいから前向きな話はあまり聞かれず，どうも愚痴に近い課題認識が多かったように感じる。いくつか発言を恣意的に切り取ってみる。 ・通信事業者はIPv6普及を啓蒙する場があるし監督官庁(総務省)も推進しているが，データセンター事業者は「監督官庁ってどこよ？」な世界｛→旗振り役がいない｝。 ・需要を取りこぼしているのに需要がないと言われてもなあ…。 ・いわゆるエンタープライズ系のIPv6対応はまったく進んでいないし，しょうがない感もあるけれど，「結構あいつら攻撃性がある」ので，エンタープライズ系にIPv6を推進する気にさせることを考えた方がいい。 ・優秀なエンジニアを古...

https://www.ospn.jp/osc2019-fall/ OSSコンソーシアム／データベース部会の立場から，PostgreSQLなどDB関連の発表を中心にレポート。 お天気ですか？教えて下さい、Postgres https://www.ospn.jp/osc2019-fall/modules/eguide/event.php?eid=67 https://medium.com/pgsql-tw/osctokyo2019fall-postgres-312b35f42ed1 COSCUP (台湾で開催されているOSSイベント) からの出張セッション。 発表者の古永忠(グヨンジュン)さんは，データベース研究者 兼 DB分野で民間の仕事もしているっぽい。今回，日本語で発表するために特訓してきたらしい。立派！ 日本のProject Tsurugi (劒) の紹介スライドがはさまっていたので，これにも関わっているのか？とも思ったが，そうではなくて，PosgreSQL関連での最近の話題を持って来ただけなのかもしれない (←結局この点ははっきりしなかったので，今度ノーチラスの目黒社長と飲むときに聞いてみよう)。 発表は，PostgreSQLを外部データソースと連携させるFDW (Foreign Data Wrapper) の紹介。天気の外部データを呼び出すのを例として示していたのがタイトルに表れている。また，「envFDW」という環境変数をデータソースにしてしまうツールも紹介。 Taiwan PostgreSQL User Group がGitHubで公開しているものらしい。「環境変数はデータベースなのか？」とツッコミたくなる点はさておき，以外と便利な小技になるかもしれない。 IoT からデータ解析の道筋での PostgreSQL の使われ方 https://www.ospn.jp/osc2019-fall/modules/eguide/event.php?eid=77 日本PostgreSQLユーザ会のセッションだが，内容は発表者の佐藤氏が仕事でやっていることだろう。鉱山(金の採掘をしているみたいだったけど，さて，どこだろう？)でのIoTのチャレンジと，そこでPostgreSQLがどのように活用されているかという話。さすが貴金属の世界で，わずか...

かつて「家電見本市」だったCEATECは家電産業の斜陽と共に衰退し…，ということはなく，すっかりICT系に宗旨替えしてしまった。そのおかげで，私たちIT屋にも参加しやすいイベントになった。展示会以上にカンファレンスのプログラムには「IoT／AI／5G」のキーワードが並ぶので，ネタ仕込みには好都合。 あと，CEATECカンファレンスの特徴として，いろんな業界団体が，その団体の企画セミナー枠を持っていることが挙げられる。 ・JEITA (電子情報技術産業協会) 　　　…CEATECはこのJEITAが中心のはず(たしか) ・CIAJ (情報通信ネットワーク産業協会) ・TTC (情報通信技術委員会) その他，いろんな協議会やコンソーシアムも。たしか昨年は学会枠もあった。 プログラム = https://reg.jesa.or.jp/?act=Conferences&event_id=9 ■聴講メモ 幕張に足を運んだのは1日だけだが，JEITA(電子情報技術産業協会)と，CIAJ(情報通信ネットワーク産業協会)の企画セミナーに参加。 ◆「AIに関するルール・標準化の現状と今後の展望」(JEITA 国際戦略・標準化セミナーから) https://www.ceatec.com/download/ja/3S-3310-1.pdf AI関連のルールは，各国政府による「規制」ならばありそうな話だが，国をまたがってのルールなんてものがはたして成立するのかが疑問だった。さらに，標準化なんて，国際機関・標準化機関は考えそうなことではあるが，標準化の様な“型にはめる”ことが受け入れられそうな気がまったくしない。…と，かなり懐疑的な姿勢で聴講したのだった。でも，結果的にはこの懐疑心は払拭されることになる。 AIに関するいろんな心配事があるのは周知の事実 (「シンギュラリティの到来」みたいな無益なFUDではなくてもっと具体性のある心配事がいろいろある)。それらの具体的な心配事に対して，業界団体，標準化機関，各国政府，国際機関が，けっこう地に足の付いた活動をしているみたいだ。 もちろん，心配事が全部スッキリ解決できる様なルールや標準が完成しているわけでは無いし，そういう類のものは将来的にもできないとは思う。しかし，心配事を軽減できるようなガ...

オープンソースカンファレンスの企業IT向け特集である“.Enterprise” https://www.ospn.jp/osc2019.enterprise/ が開催。私が関与しているOSSコンソーシアムとオープンソースビジネス推進協議会(OBCI)の両方が共同で，企画セッションを実施。ほぼ満席に近い方に参加いただき，関心の度合いはまずまずといったところ。 ITモダナイゼーション(≒オープンソースのCOBOL処理系)と，OSSデータベース3種の最新状況という，ごった煮的なパッケージにしてしまったが，OSC向けの企画としては良かったんじゃないだろうか。 ■概要と発表資料 OSSコンソーシアムのWebサイトにて公開中。 →  https://www.osscons.jp/jo59bukqa-723/#_723 ■内容の報告は… 11月1日に公開予定の， gihyo.jp - 「OSSデータベース取り取り時報」 の第51回 (10月24日時点では未発行) にレポートを掲載。乞うご期待。 --

最近，違うスジのところで独立して発信している情報が「なぜかシンクロしているな」と思うことがある。そのひとつが，この「ソフト開発じゃなくてもアジャイルしようぜ」というメッセージ。Gartnerレポート「アジャイルなI&O文化を実現する後続の5ステップ 」(INF-18-123 (G00343458), 2018年8月)では，I&Oチーム(要はインフラチーム)もアジャイルしろと言っていた。今回のIPAの資料では，「従来はソフトウェア開発のための手法だったが今はそれだけじゃない」と。 「アジャイル領域」関連資料『なぜ，いまアジャイルが必要か？』，『ビジョンとプロダクトの橋渡し』 を公開，IPA，2019年4月12日, https://www.ipa.go.jp/jinzai/itss/itssplus.html#section1-4 ■IPA文書のメッセージ概要 『 当初アジャイル開発はソフトウェアエンジニア主体の開発手法でしたが，近年は不確実さに対応するビジネス戦略としても採用され始めて 』いると。つまり，IT企業の中で技術部隊ではあるけどソフトウェア開発をしているわけではない連中だってアジャイルを意識した方がいいということになる。ここで，ソフトウェア開発をしていない連中というのは，私としてはSI企業内インフラ屋のことを指しているつもり。(ただしIPA的にはもっと広い意味で使っている)。 ■公開文書の体系 今回，上記のWebページでは次の様な文書が公開されている。 　(1) アジャイル領域へのスキル変革の指針 (本ドキュメントの位置づけ) 　(2) なぜ，いまアジャイルが必要か？ 　(3) アジャイルソフトウェア開発宣言の読みとき方 　(4) ビジョンとプロダクトの橋渡し（プロダクト責任者） 　(5) アジャイル開発の進め方 　他 ■まずは... まずは (1)〔なぜ，いまアジャイルが必要か？〕の資料から入るのがいい。結局のところ意識を変革できるかどうかがすべてなので，これだけ読んで意識が変わるなら，それだけでもいいかもしれない。さらに言えば，実際にアジャイル開発手法を採用するかどうかは，この文脈の中ではどちらでもいいのではないかとすら思う。 ■なぜアジャイルか？ 『 Society5.0時代は...

またまた，とても雑なメモ書き: https://tech.nikkeibp.co.jp/atcl/nxt/mag/nnw/18/NNW_backnumber/201909/ 特集テーマは「ハードウェアハック」。通信の用途や通信プロトコルなどの一般的なテーマ設定だと，どうしてもソフトウェアの話に偏るから，あえてこういうテーマ設定にしたのだろうか。まぁおもしろい観点ではある。 けれど，内容的にはパケットキャプチャ話が多い。前月号の特集「パケットキャプチャ」の続きみたい。前月号から漏れた内容を今月号にまとめたのかもしれない。 【パケットキャプチャ話から関心を持った点】 「Burp Suite」 … Javaで動き、HTTPS(TLS)もキャプチャできる。 「PacketLogger」 … macの開発ツールに含まれて、Bluetoothをキャプチャできるツール。 無線LANのキャプチャ … macOS標準の「ワイヤレス診断」で、追加ハードもソフトも必要とせずに無線LANのキャプチャができる。 (一般的にはL2のデータをフレームと呼ぶが)“ただしフレームを取得することも、「パケットキャプチャー」と呼ぶのが一般的” → たしかにそうだね。 【その他】 「DPDK」(Data Plane Development Kit)= アプリ(の中のライブラリ)からNICを直接制御 → 高速 → NICのWire speedまで使える。 JR山手線の超音波通信 … おもしろい --