米IBMとHashiCorpは4月24日(現地時間)、IBMが1株あたり35ドル、企業価値64億ドル(日本円換算で約1兆円)でHashiCorpの買収について、確定的な合意に達したと発表した。HashiCorpの製品群は、企業がハイブリッドクラウドとマルチクラウド環境を自動化するためのインフラストラクチャライフサイクル管理とセキュリティライフサイクル管理を可能としている。
[...]このNekoFightのAIに今回冒頭で挙げた記事のED(誤差拡散)法という学習法が使われている。
言うまでもなく、現代のDNN(Deep Neural Network)の学習で用いられるのはほとんどがBP(誤差逆伝播)法である。
ED法は、BP法のように後ろ(output)から前方(input方向)に逆伝播して学習させずに学習できてしまう。詳しいことは、冒頭で挙げた記事を読んで欲しい。
しかし、これはSNN(Spiking Neural Network)ではないのだろうか。私にはSNNとの違いがよくわからない。SNN自体は、ED法以前に考案されているので、ED法自体に新規性があるのかは私にはよくわからない。SNNに関しては次のサイトがよくまとまっているので参考にして欲しい。
ゼロから学ぶスパーキングニューラルネットワーク : https://snn.hirlab.net/
それで、ある日の日記によると、今回のED法を金子さんが論文として書いたが、rejectされたっぽくて、その愚痴が長々と書いてあった。(その愚痴は翌日ぐらいには消されてたように思う。記憶が不確かなので違うかも？)
まあ、金子さんは「人間の神経細胞はこうなってるんじゃないか」みたいな仮定のもとにED法を考案してるので、この仮定の部分に関しては(悪く言えば)ただの妄想に過ぎないし、BP法より性能が劣るのではどこに優位性があるのかよくわからん状態だし、それってSNNじゃね？新規性ある？(SNNはそれ以前に発表されている)みたいな状態では、rejectされるのも仕方ないのかなーと私は思うんだけど、そのへんが金子さんは納得いってない様子に見えた。(私の感じた印象です。識者の意見を聞きたいです。)
いずれにせよ、BP法は、チート性能だ。人間より遥かに少ないニューロンで人間より高い性能が出せる(ことがある)のは、このBP法のお陰だと言っても過言ではないと思う。人間の脳はBP法なんて使っていない。使わせてもらえていない。だから学習がこんなに非効率なのだ。社会人になるまで平均的には20数年かかけるのも、学習が非効率すぎるからだと言えよう。
江崎グリコは2024年4月19日、乳製品・洋生菓子・果汁・清涼飲料など「チルド食品（冷蔵品）」の出荷業務を再度停止したと発表した。同社は4月3日に旧基幹システムを独SAPの「SAP S/4HANA」に切り替えた。その後システム障害が発生し、物流センターの一部業務を停止。復旧作業に取り組んでいた。
同社は4月18日に一部業務を再開したものの、「物流センターでの出荷に関するデータ不整合などが発生したほか、想定していた受注に対して処理が間に合わず、出荷の停止を判断した」（江崎グリコ広報担当者）。再開は5月中旬を目指している。常温品や冷凍品など、冷蔵品以外の商品は出荷している。
2024年4月3日(水)、基幹システムを切り替えた際に発生したシステム障害により、乳製品・洋生菓子・果汁・清涼飲料などの「チルド食品」（冷蔵品）につきまして、現在、一部の受発注及び出荷業務に影響が出ております。
基幹システムの障害発生以降、当社の「チルド食品」（冷蔵品）を取り扱う全国の物流センターにおける業務を一時停止したうえで、全面的な復旧を目指しておりました。
しかしながら、18日(木)より一部再開したものの、物流センターでの出荷に関するデータ不整合等が発生したほか、想定していた受注に対して処理が間に合わず、出荷の停止を判断しました。お客様およびお取引先様にご迷惑をお掛けしております。
「チルド食品」（冷蔵品）の出荷業務を再度停止させていただき、5月中旬の再開を目指して復旧作業に努めてまいります。なお、「チルド食品」（冷蔵品）以外の商品(常温・冷凍)の出荷業務は、継続して行っております。
お客様およびお取引先様には、多大なご迷惑とご心配をお掛けしており、謹んでお詫び申し上げます。一刻も早い復旧に向けて引き続き全力で取り組んでまいります。
ご不便とご迷惑をお掛けしておりますが、何卒ご理解賜りますよう重ねてお願い申し上げます。
以上
ひぇぇ
人間は意識が高まってしまうと他人に説教を始めてしまう生き物
偏見多めでいうと技術者に人間的魅力 (清潔な服を着ている、髪・眉毛が整っている、話し方がこなれている、笑える雑談ができる etc) が低い人が多いのって、魅力が低いから「謝って人に許された経験」がないので「謝って許してもらえないのは人も機械も一緒」という認知が形成されているからでは…
高校の同級生でプログラマになってすぐ辞めたやつは、バグは謝っても許してくれないけど、人間は謝れば許してくれるからちょろいって言ってたなー。
信じられんなと思いながら聞いていた。
富士通Japanは4月16日、住民票のコンビニ交付システムで証明書が誤交付されたと発表した。香川県高松市で申請者とは異なる住民の住民票が発行されたという。同社のコンビニ交付システムでは、2023年にも複数回の誤交付が発生していた。
高松市では1月4日から、富士通Japanのコンビニ交付システム「Fujitsu MICJET コンビニ交付」を導入していた。しかし、コンビニ交付サービスの項目でシステムの設定ミスがあり、4月4日に別人の住民票が誤交付される事象が発生した。
富士通Japanのコンビニ交付システムを巡っては、23年にも同様の不具合が複数回発生しており、5月末から6月初頭にかけてサービスを停止してシステムを一斉点検する事態に。同社は再び同じ問題が発生したことについて、謝罪し「今回の事象を重く受け止め、あらためて深くおわび申し上げるとともに、全力を挙げて再発防止に努めてまいります」と表明した。
なお、この件について総務省は行政指導を実施。原因の究明の他に「令和5年（2023年）に総点検を行った上で再発防止を図ったにもかかわらず、今回の事案が発生したことを踏まえ、国民・住民の信頼回復につながる徹底した実効性ある再発防止対策を講じること」などを命じている。
あらら...
米Microsoftの研究チームが発表した「BitNet」、通称「1bit LLM」と呼ばれる論文が波紋を呼んでいる。これまでのLLMとは違い、演算が軽くなるのに精度が上がり、そしてこれまで必須だと思われていたGPUが不要で、CPUでもLLMが動作することを示唆している。
2019年になると、NetflixはCassandraに限界を感じ始める。当時、Netflixは需要の増加と日増しに高まるデータベース要件に悩まされていた。Cassandraではリッチなトランザクションを組むことができず、グローバルレベルで一貫性のあるトランザクションをサポートすることが困難だった。またセカンダリ・インデックスは信頼性が低く、機能しないことが多かった。そこでAWSの AuroraやDynamoDBを候補に考えたが、いずれも要件を満たさなかった（参照："The history of databases at Netflix: From Cassandra to CockroachDB"）。Auroraは書き込みはシングルリージョンのみでスケールしない点、DyanamoDBは結果整合性しかなくSQLインタフェースがない点で敬遠されたのが分かる。
2020年、Netflixは最初のCockroachDBクラスタを本番環境にデプロイした。環境としてはAWS EC2とEBSが使われている。現在では100の本番クラスタと150以上のテストクラスタがある。2023年時点では、ほとんどのクラスタは3つのアベイラビリティゾーンを持つ単一リージョンにデプロイされている。Netflixで最大のCockroachDBクラスターは60ノード、単一リージョンのクラスターで、26.5テラバイトのデータがある。これだけの規模のデータで高トランザクションをさばきつつ監視やバックアップまで実現できているというのは、かなりすごいことだと思う。CockroachDBはまだ日本語のサポート窓口がないのだが、筆者が一番期待しているNewSQLの実装なので、早く日本進出してくれないかなと思っている。NetflixのほかにDoordashやSpotifyなどメガウェブサービスで利用されているので、エンタープライズにも適合する可能性が高いのではないかと期待しているのだ。
オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。
けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。
「現実をモデリング」をやろうとすると、どんどんコーナーケースがでてきて、そのすべてのコーナーケースに対応しようとすると、結局は細胞モデルや分子モデルなど、微細要素まで分解してシミュレーションすることになっていきます。
そもそもモデリングというのは抽象化なので、現実のシミュレーションではないですね。
そして抽象化というのは、必要な要素を残して不要な細部を切り捨てる作業です。では何を残して何を切り捨てるかというのは、何に使うかということなしには決めれません。
モデリングでは「何に使うか」が重要です。
目的が決まっていないモデリングは、モデリングのためのモデリングになってしまいます。
結局のところ、モデリングするべきは、モノではなくプロセスです。プロセスをモデリングしたあとで、そのプロセスを可能にするデータとしてモノをどうあらわすかというモデルが必要になるわけです。
オブジェクト指向が衰退した流れのひとつに1990年代後半に開発手法から開発プロセスに関心が移ったことを取り上げるのですけど、90年代後半にビジネスプロセス・リエンジニアリング(BPR)という言葉が流行りビジネスプロセスを分析設計することに関心が集まったこともオブジェクト指向の衰退に無関係ではないのかもしれません。
単に「自分の食い扶持が脅かされて怖い＞＜」というゴミのような意見でしかなく、ラッダイトの主語を大きくしてはいけない（戒め）
DBOSの開発は2022年に始まった。DBOS Inc.の共同創設者であるPeter Craft氏とQian Li氏は最初のブログ投稿で次のように書いている。「次世代のOSはデータベース指向であるべきだと考えている。というのも、データベースは現代のコンピューティングの困難な問題を解決するために構築されているからだ。現在のデータベースは、ペタバイト規模のデータを管理でき、分散化されて、クラウドネイティブ化が進んでおり、きめ細かなアクセス制御と来歴追跡によるデータの保護と管理が可能だ。同様に重要なことに、VoltDBや『FoundationDB』といった現代的な分散型インメモリーデータストアは、極めて高速になりつつある。後で示すように、それらは従来のディスクベースのリレーショナルデータベース管理システム（RDBMS）では実行できない多くのOSサービスを効率的に実行できるほど高速だ」
両氏はさらに、以下の2つの原則に基づいたデータベース指向OSの構築を提案した。
- すべてのアプリケーションとOSの状態が、分散データベースのテーブルに保存される。
- 状態には、データベーストランザクションによってのみアクセスできる。
このOSは以下の4つのレベルで構成されている。
- ユーザーアプリケーション
- ファイルシステム／スケジューラー／IPC／その他のOSサービス
- 分散DBMS
- マイクロカーネルサービス
DBOSでは、OSのサービスが分散DBMSにおいてSQLでコーディングされる。これは、データベース管理システムをOS上のユーザー領域内で実行する従来の方法と大きく異なる。
DBOSの最大の利点の1つは、信頼性の高い実行だ。すなわち、アプリケーションが中断しても、止まったところから自動的に再開される。
SIM Appletとはなにか
SIMカード（ICカード）にはJava Cardランタイムが搭載されていて、独自のJavaAppletを動かすことができます。 端末やネットワークと対話するための仕組みがSIM Toolkitとして提供されており、これらを使って作られたプログラムをSIM Appletと呼んでいます。
日本国内の状況
一般に発売されているSIMカードでは、ユーザーが自由にSIM Appletを開発して搭載すること困難です。
そんな折、SIM内の通信プロファイル領域とアプレット領域を分けて管理できる「アプレット領域分割技術」がNTT Communicationsから発表されました。この技術によりユーザーが自由にSIM Appletを載せることを可能になっています。
NTTコミュニケーションズ（NTTコム）は2024年4月9日、暗号化されたJavaアプレット領域の一部を顧客に開放したSIMカードの本格提供を始めたと発表した。顧客企業が同領域に決済情報・個人情報・設定情報などを安全に格納できるようにし、IoT（インターネット・オブ・シングズ）などのサービスを展開しやすくする。価格は個別見積もりだが、SIMカード1枚当たり月額100円程度から、管理コンソール機能は同1万5000円程度からを見込む。
同社が「アプレット領域分割技術」と呼ぶ技術により、SIMカード内にあるJavaアプレット領域のうち約300キロバイトを切り出し、顧客企業が独自に暗号鍵を管理して利用可能にした。SIMカード上のCPUやメモリー、OSなどと組み合わせて、認証などのアプリケーションを実行できる。同技術による領域の切り出しはSIMカードの製造時に書き込むソフトウエアにより実現しており、物理的な構造は通常のSIMカードと変わらない。
最近 moonbit という言語を知ったのですが、これが調べれば調べるほど好きになる言語だったので、紹介させてください。
文法的には GC 付きの Rust で、 WebAssembly にコンパイルされます。とくに CDN Edge Worker 上での実行を想定しているようです。もう好き。
注意: まだ若い言語なので、これから言語仕様がガンガン変わっていくと思われます。あくまで現時点での情報です。
プログラマーの中には、「〇〇言語は実用的でない」と言ってしまう人がいるんだけど、「学校の勉強は役に立たない」と言っているぐらい恥ずかしいからやめた方がいい。
勉強を役立てられなかったと同様に、そのプログラマーが実務で使いこなせなかっただけなのだから。
「〇〇言語は嫌い」はいいよ。
好き嫌いだからね。
実用性について言うなら、もっと謙虚に「僕は〇〇言語を実務で活用できませんでした」と言うべき。
[...]さて，ここまで，b1.58論文の中身について解説してきましたが，いかがでしたでしょうか．個人的には，この論文には賛否両論があると考えています．
否定的な見地からは，論文としての品質が十分に高いとは言えない点が挙げられます．ここまで，問題点をいくつか具体的に挙げてきましたが，ほかにも，先行研究として引用すべき文献，たとえば文献4）や文献5）が引用されていない点も気になります．
一方で，肯定的な見地からは，精度の逆転現象が本当ならば大きな発見であり，自然言語処理分野への大きな貢献となり得る，と言えます．もしこの実験結果が本当ならば実用上の効果は大きいですし，それだけではなく，この発見をきっかけにニューラルネットワークの性質についての新しい知見が得られる可能性もあります．
ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。
ということで、Goの開発者やGooglerが何か特別なポリシーや宗教上の理由でスタックトレースをエラーに付けていないわけではありません。単に影響範囲がデカい言語仕様だとかコアライブラリの新規APIに対する仕様追加に極めて慎重で時間をかけてるだけでした。エラーにスタックトレースをつけるライブラリを使っても、Go Wayに違反して善きGopherになれなくなるなんて事は全くないので、安心して使えば良いと思います。
その際は他のライブラリの選定の時と同じく、信頼性のあるソフトウェアを参考にしつつ、依存ライブラリの数やシンプルさ、将来Goの標準ライブラリに追加された時に移行しやすそうかなどを考えて選べば良いでしょう。 特に1つのライブラリをお勧めできるほどGoのエコシステムに詳しいわけではありませんが一例として、CockroachDBは（名前が最悪なのはともかく）Goで書かれた信頼性の高いソフトウェアなので、 github.com/cockroachdb/errors は参考になるかもしれませんし、分散システムを作るのでなければ複雑すぎるかもしれません。
Goを使ったプロジェクトでたまに遭遇する「Goらしさ（Goらしくない）」という定義の曖昧なコメントを見る度にイライラしていた。
about:configと入力Red HatやDebianを含むLinuxディストリビューションで広く使用されている圧縮ツール「xz」の最新版に悪意のあるバックドアが含まれていた事がわかりました(Ars Technica)。
発見した開発者のAndres Freund氏は、xz version 5.6.0と5.6.1に悪意のあるコードが含まれていることが分かったと指摘しています。幸い、このバージョンは主要なLinuxディストリビューションの製品リリースでは使用されていませんが、Fedora 40やFedora Rawhide、Debian testing/unstable/experimentalなどのベータ版リリースには含まれていたそうです。
Red Hatはユーザーに対し、Fedoraの開発版や実験版の使用をただちに終了するよう警告し、セキュリティ問題を「CVE-2024-3094」(重大度スコアは10/10のクリティカル)として追跡しています。またDebianのセキュリティチームも、この問題についてユーザに警告しています。
SQLは「情報処理分野で最も 成功した国際規格」と言われているのだけど、なんでこんなに成功したのかはよく分かんないんだよね。開発元のベンダやコミュニティはバラバラで標準にも強制力はないのに、みんなビシッと準拠してくるのが不思議。昔はもっとバベルな感じだったのにな。
ライバル製品から顧客を奪い取る為には「ライバル製品ができること」をコンプリートしている必要があったからかな
Linux Foundationは2024年3月28日、Redisに代わるオープンソースの新しいインメモリキャッシュストアシステム「Valkey」のコミュニティを立ち上げ、開発を行うことを発表した。
このプロジェクトは先に発表されたRedisのライセンス変更に対応して発足したもので、Redis 7.2.4の開発を継続し、BSD 3条項ライセンスの下でオープンソースとしてプロジェクトの使用と配布を続けていく。
ValkeyプロジェクトにはAWS、Google Cloud、Oracle、Ericsson、Snap Inc.などの企業がサポートを表明しており、元RedisメンテナーでAWSのチーフエンジニアであるMadelyn Olson氏が共同制作者として参加しているほか、元RedisコントリビューターのGoogle Cloudエンジニアなどが開発に加わっている。
本記事では、Aurora MySQL でロック競合（ブロッキング）起因のタイムアウトエラーが発生した際に根本原因を特定することができなかったので、原因を後追いするために必要な情報を定期的に収集する仕組みを構築した事例をご紹介します。尚、考え方自体は RDS for MySQL や、AWS 以外のクラウドサービスの MySQL の PaaS および、MySQL 単体にも適用できるものかと思いますので参考になりましたら幸いです。
チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。
また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。
参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少なかったり、前提する情報が多く、そのまま紹介するのは難しいことが多かったです。
余談ですが、もちろんベストプラクティスを使うことは悪いことではないと思っています。ただ、「ベストプラクティスだから」というという理由で仕組みをわからずに使っていると、前提となる状態が変わった時に判断を誤ることがあります。
Oreillyから出版された「Fluent React1」は、そういった状況に対して、役立つ情報を提供してくれると感じたのでこのブログで紹介します。
基幹系システムのような社内システムにおいても、オープンソースソフトウエア（OSS）の利用が当たり前になってきた。クラウドサービスを利用する場合や、開発担当者と運用担当者が連携する開発手法DevOpsを採用する場合など、OSSの利用を避けられない。
多くの企業でOSSの利用が進む中、OSSを採用した当初は想定していなかった誤算に直面するケースが浮上している。商用のソフトウエアに比べてサポート期間が短かったり、サポートが充実していないため脆弱性が見つかっても放置してしまったりといった課題だ。ユーザー企業は安易に導入コストだけを見てOSSを採用するのは禁物だ。その後の長期間の運用・保守も含めた体制の検討が求められる。
Redisは2024年3月20日、次のバージョン（Redis v7.4）以降、これまで採用してきたBSD 3条項ライセンスから、RSALv2（Redis Source Available License）もしくはSSPLv1（Server Side Public License）のいずれかを選択するデュアルライセンスに移行することを発表した。
RSALv2はRedisの機能拡張であるRedis Stackなどで採用されているライセンスで、ソフトウェアを商品化したり、マネージドサービスとして他者に提供することができない。ライセンス、著作権、その他の通知を削除したり隠すこともできない。
またSSPLv1はMongoDBなどが採用しているライセンスで、ソフトウェアを「サービス」の一部としてサードパーティが利用できるようにする場合、修正されたかどうかにかかわらず、そのソースコードをすべて公開する必要がある。公開範囲はユーザーがサービスのインスタンスを実行できるようにするすべての管理ソフトウェア、ユーザーインターフェイス、API、自動化ソフトウェア、監視ソフトウェア、バックアップソフトウェア、ストレージソフトウェア、ホスティングソフトウェアなどが含まれる。
このため、組織内でのRedisの利用についてはこれまでと同様だが、Redisをクラウドサービスなどで提供する場合は制限が適用されるケースが出てくることになる。
またこれにともない、製品名として「Redis」または「for Redis」という記述を使用することもできなくなる。製品の説明で「Redis」という名前を使用したり、Redisと互換性がある、または以前のバージョンのRedisに基づいていると記述することはできる。
当時、jQueryは「サイズが大きくてパフォーマンスが悪い」ものとして厄介払いされようとしていました。 bundlephobiaによると[3]、ミニファイされたjQueryのバンドルサイズは85.1kb、GZIPされたものは29.7kbです。読み込みまで遅い3G回線なら0.59s、4G回線でも34msかかるそうです[4]。
現在いちからWebサイトを作ろうとするなら、フロントエンド開発者ならNext.jsなり、RemixなりReactのフレームワークを立ち上げて作るでしょう[5]。しかし、そうするとなんと、10年前のJQueryをCDNで読み込んだサイトと似たような問題を抱えることになります。 Reactは「サイズが大きくてパフォーマンスが悪い」です。
Reactを使うときはreact-domを一緒に使います。bundlephobiaによると[6]、ミニファイされたreact-domのサイズは130.2kb、GZIPされたものは42kbです。読み込みまで遅い3G回線なら0.84s、4G回線で48msかかるそうです。
この記事を書くために調べてちょっと驚きましたが、ReactはjQueryよりも重いのです[7]。
株式会社ユリ電気商会（本社：大阪市北区・代表取締役：木内 正人）は、2024年2月29日に「Kaki Pi（カキパイ）」としてプレスリリースした開発中の小型コンピュータのブランド名を「Kakip（カキピー）」に改定し、今後のシリーズに展開していくことを発表しました。
Kaki Piは発表後、短期間で多くのメディアやSNS上で取り上げていただき、様々な方面からご期待の声もいただいております。話題として取り上げていただく中で、たとえ法的な制約がなくとも、その名称により他社製品との混同が生じたり、将来的な販売店での取り扱いや企業ユーザーでのご採用に影響を与えたりする可能性がある、と弊社は判断致しました。
発売前の現段階でブランド名を変更しておくことが上記のような将来目標の実現の為に適切な措置であると判断し、入念なリーガルチェックを経て「Kakip（カキピー）」という名称に改定することといたしました。
つまりレビュアーに承認を求めることは、「却下すべき理由を探す」ことを求めているのである。 そして「却下すべき理由を探す」ということは、その事柄に対して批判的・悲観的な立場に立つことと同じである。 「保障プロセスとして機能するレビュー」において、レビュアーは間違いなく批判者である。 レビューで批判的立場から却下されるということは、そのレビューが保障プロセスとして機能していることの表れともいえる。
※あくまでも＜事柄＞に対しての批判であり、レビュイーの＜人格＞への批判は求められることではない。
その前提を踏まえた上で、レビューを依頼するときには「承認をもらいにいく」（支持してほしい）のではなく、自分とは違う視点から「検証してもらいにいく」（見落としを見つけてほしい）というマインドでいること、それがレビュアーに対して優しさを期待することに諦めがつく気の持ちようではないかと思う。
また、レビュアー側も「保障プロセスとして機能するレビュー」にするために批判的立場からコメントすることをあらかじめエクスキューズしておくことで、不都合な衝突を起こすリスクを減らすことはできるだろう。
「行政指導でここまで踏み込んだ文書は、あまり見たことがない。次こそは許しませんよ、というメッセージだろう」
総務省は3月5日、SNS「LINE」や検索サービス「Yahoo! JAPAN」などを運営するLINEヤフーに行政指導を行った。その指導内容を記した文書を見た通信業界関係者は、驚きの声を上げた。
LINEヤフーは2023年9～10月、LINEの利用者や取引先の情報など約51万9000件を外部に漏洩させていた。総務省はこのうち2万件以上が電気通信事業法上の「通信の秘密」の漏洩に当たると判断した。
具体的な指導項目として、LINEヤフーの親会社に50％出資する韓国のIT大手、NAVERとのシステムの切り離しや、グループ全体のセキュリティガバナンス体制の強化などを要請。その取り組み方針などを4月1日までにとりまとめたうえで、今後少なくとも1年間は、四半期ごとに総務省に対応状況を報告することを求めている。
行政指導に当たって総務省がまとめた10ページに及ぶ文書には、苛立ちすら感じ取れるような厳しい言葉が並ぶ。
「旧LINE社に対しては、（中略）アクセス管理の徹底等も含めて行政指導を行っていたにもかかわらず、なおもアクセス管理の不備を一因とする本事案を招いた」
「電気通信事業全体に対する利用者の信頼を大きく損なう結果となったものであり、当省として極めて遺憾である」
さらに、委託先であるNAVER側への適切な管理・監督を機能させるため、親会社も含めたグループ内における経営体制の見直しの検討にまで言及している。
goqite (pronounced Go-queue-ite) is a persistent message queue Go library built on SQLite and inspired by AWS SQS (but much simpler).
goqite (Go-queue-ite と発音) は、SQLite 上に構築され、AWS SQS からインスピレーションを得た永続メッセージ キュー Go ライブラリです (ただし、はるかに単純です)。
SQLiteを永続層に持つメッセージキューライブラリ。Goで実装されている。
米Microsoftは3月12日（現地時間）、「Visual Studio Code」用の「Unity」拡張機能を一般公開した。昨年8月からプレビューテストが続けられていたが、ようやく正式版として利用できるようになった。
「Unity」拡張機能は、Windows/Mac/Linux環境の「Visual Studio Code」で「Unity」コンテンツを開発するために必要な機能をまとめたツールキット。同社はすでに、「Visual Studio」向けに「Unity」開発のプラグインとして「Visual Studio Tools for Unity」を提供しているが、Mac/Linuxをカバーする「Visual Studio Code」でもそれに迫る生産性を享受できる。
3月も半ばになり、暖かい日も増えてきました。これだけ暖かくなってくると、ちょっとしたアプリで少し特殊なネットワークフレームを流したり、普段使わないネットワークプロトコルを試したくなりますよね。でも本番環境でそれをやってしまうと、変質者としてしかるべき場所に通報されてしまいます。そこで今回は他人に迷惑をかけずに隔離されたネットワークテスト環境を構築できる「mininet」を使って、お縄にかからないようにしてみましょう。
EU首脳は最近、RISC-Vベースのチップ開発を推進するためのイニシアチブをいくつか開設した。これは、加盟国が半導体の開発／製造を外国企業に依存していることを懸念する声に対応するためのものだ。近年では世界的な半導体不足によって、サプライチェーンに混乱が生じ、半導体主権の重要性が浮き彫りになっていることから、こうした懸念がさらに高まっている。
RISC-Vは、オープンソースの命令セットアーキテクチャであり、どの企業にも所有されていない。このためEUにとっては、優れた柔軟性と安全性を実現することが可能な、魅力的な選択肢となっている。
Valero氏は、「英国のEU離脱や、ソフトバンクによるArm買収の後、EUには、欧州独自のプロセッサが存在しなくなるという問題があることが分かっていた。だがそれは、7年前にRISC-Vが登場するまでのことだった。RISC-Vは欧州をはじめ、世界中のあらゆる企業がプロセッサを作ることができるという可能性を開いた。米国や欧州、中国が命令セットを決定するのではなく、グローバルな命令セットであるからだ」と述べる
2023年12月1日から働き始めた株式会社令和トラベルを3月19日付けで退職します。1984年4月1日から社会人として働き始めてから9社目の会社でした。9社の中で最も在籍期間が短かった会社となります。
私自身は、今年の11月で65歳になります。ウェブサービスの業界で働き続けるとしたら、API仕様ファーストおよびE2Eテストによるテストファースト開発を経験するエンジニアを増やしていければと思っています。もちろん、私自身もソフトウェア開発を続けたいのは以前と変わりません。しかし、私自身が正しいと思わない方法でソフトウェア開発を続けたくなかったので退職することにしました。
単体テストでDBに依存すべきじゃない → じゃあスタブに置き換える → 現実とテストコードが一致しなくなってあぼーん みたいな話よくあるつらさ
今回は、昨年11月に開催した、テストとリファクタリングのためのワークショップの中で行ったライブコーディングの準備をするにあたって困ったことについて記載します。
しかし長年の間に、このコミュニティ中心のアプローチは変化してきている。Ubuntuは今でもエンドユーザーが使いやすいディストリビューションのままだし、大手ベンダーが手掛けるLinuxの中では、いまだにデスクトップLinuxの火を消さないよう強力にサポートしている唯一のディストリビューションなのだが、Ubuntuが今一番使われているのは、クラウドや、サーバーや、IoTの分野だ。
CanonicalはLinuxの将来に影響を及ぼそうとしてきたが、成功した部分もあればそうでない部分もある。例えば2011年には、デフォルトのデスクトップ環境に新しいLinuxデスクトップである「Unity」が採用された。 その目的は、Linuxデスクトップだけではなく、スマートフォンやタブレットでも使えるインターフェースを生み出すことだった。
[...]そこで制作されたのが、今回紹介する「Moralerspace」。「monaspace」に高品位な日本語フォントを組み合わせてあり、日本語テキストが混じってもバランスのとれたレンダリングが行えるのが魅力だ。全角空白の可視化といった工夫も施されているので、ソースコードに全角空白が混じってコンパイルが通らないといった、日本語環境にありがちなミスを未然に防ぐこともできる。
ライセンスは「SIL Open Font License 1.1」。比較的縛りが緩く、個人利用・商用にかかわらず無償で、Webサイトに埋め込むだけでなく、改変して派生フォントを開発したり、アプリやゲームなどに組み込むこともできる。