一番スムーズに進んだウェブ開発プロジェクトは、ミーティングなんて週に一時間のみ、見積もりやタスク整理もろくにしてませんでした
一番上手く行ってないプロジェクトは、作業時間の半分以上はミーティングやチャット、タスク整理や見積作成で消耗してました
不思議なものですね……（白目）
「チューニング名人は設計名人にあらず。驕ることのないように」、というのはトラブルシューター時代の上司から言われた言葉。今も肝に銘じている。
米国人にタスク見積もりさせるとメールの確認みたいな日本人なら入れない細かいタスクをビッチリ入れてくるので、それはいちいち計上しなくていいのでは？ と指摘したら「情報共有のコストがタダだと思うな」という返事だった。日本人すぐ色んな人に共有メールとか送りたがるんで、教訓的だなと思った
Googleは、2024年4月23日、ChromeのサードパーティCookieサポート廃止のスケジュールを延期することを発表しました。
延期にあたり、Googleからのコメントは以下の通りです。「私たちは、業界、規制当局、開発者からのさまざまなフィードバックの調整に関する継続的な課題があることを認識しており、エコシステム全体と密接に関わり続けていきます。また、CMAが市場参加者に6月末までに提出するよう求めている業界テストの結果を含むすべての証拠を検討するための十分な時間を確保することも重要です。これら2つの重要な考慮事項を考慮し、私たちは第4四半期下半期中にサードパーティCookieの非推奨化を完了させるつもりはありません。私たちは引き続きCMAおよびICOと緊密に関わり、今年中にそのプロセスを完了させたいと考えています。合意に達することができれば、来年初めからサードパーティCookieの非推奨化を進める予定です。」
東京大学の研究グループは9日、半導体シリコンの熱放射を倍増させる技術を開発した。
高性能半導体デバイスにおいては、局所的な発熱により性能や信頼性が低下してしまうことが問題となっている。しかし研究グループでは、シリコン膜の表面をわずかに酸化させるだけで、プランクの熱放射則で決まるとされていた熱放射を倍増させることに成功した。これにより、発熱問題解消に期待がかかる。
[...]そんなZ80の生産が、誕生から48年を経ていよいよ終了するという。Tech系情報サイト『Ars Technica』が2024年4月23日に掲載した記事によれば、2024年4月15日にZilogはZ80の製造を終了する旨をニュースリリースで発表したという。
もちろん、現在販売されている製品は1976年発売当時のZ80そのものではなく、互換性のある「Z84C00」と呼ばれるマイクロプロセッサだ。しかし、その外観は当初と変わらないデュアルインラインパッケージ（DIP）のままだ。コアプロセッサ本体を長方形のセラミックまたはプラスチックで覆い、側面に20本のピンを備えるいわゆる「ゲジゲジ型」のチップだ。CPUの外観といえば、いまだにZ80のそのゲジゲジ姿を思い出す人は少なくないだろう。
クロック数など使用は若干異なるが、Z84C00チップには13モデルが存在している。その全てが製造停止になるという。ZilogはZ80と互換性のある「eZ80」を提供していて、今後はZ80の需要をeZ80でカバーするという。
また他社の互換製品も幾つか存在し、パッケージや仕様は異なるものの、Zilogの製造中止によってZ80を今後も必要とする業界が大きく混乱することはなさそうだ。ただ、古式ゆかしいあのゲジゲジ姿が消えてしまうのは惜しいところだ。
「総合テストで障害がでることは許されません、他の案件でも総合テストはいつも障害ゼロです」って某銀行の人に本気で言われたことがあります。仕方ないから前工程で総合テストケース全部やって障害も潰して、意味ないなと思いつつ全く同じケースを総合テスト工程でやりました。もちろん障害はゼロ。
保守運用をケチる → みずほ銀行
セキュリティを軽視する → 7pay（セブンペイ）
基幹システムの切替を甘く見る → グリコ
ITプロジェクトのしくじり三銃士になりそう。
「もうデスマーチが始まってますよ」。自治体情報システムの開発を手掛ける複数のベンダー幹部は口をそろえる。自治体は2025年度末までに主なシステムを標準仕様に準拠させ、政府が契約したクラウドサービスに原則移行しなければならない。ところが標準仕様の改版が続いている上に、岸田文雄政権の経済政策に伴うシステム改修が追い打ちをかけているためだ。
「全システムをこれだけの規模で一斉に切り替えるという作業はやったことがない」。あるベンダーの幹部はこう語る。全国約1700の自治体はまず、2025年度末までに計20の基幹業務システムを標準仕様に基づいて一斉に作り直すという、前代未聞のシステム改修を迫られている。
さらに、政府が決めた2025年度末という期限は、自治体システムに特有の事情を加味すると前倒しが欠かせない。文字通り解釈すれば2026年3月末が期限だが、事実上2026年1月末が移行期限という。自治体の現場は年前半が繁忙期になるためだ。
⾃治体において毎年2⽉中旬から確定申告が始まると、この納税データを使う住民税などの課税処理が集中する。新年度の前後は転居に伴う転入・転出手続きがピークを迎える。導入時に自治体の繁忙期を避けようとすると、2024年5月現在で残された時間は実質1年半ほどしかないわけだ。
つまり全国の自治体は今後1年半ほどでガバメントクラウドの構築作業や、アプリケーションやデータ移行を自治体職員が確認する作業、さらには既存システムや外部システムとの接続テストなどを一気に進める必要がある。もちろん20業務のシステムの組み合わせは自治体によって異なるので、各自治体の状況に合わせて対応する必要がある。
でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。
レポートの講評:最初の着眼点はよかったです。歴史と海外に目を向けるとなお良かったでしょう。大体自分が考えつくことは既に誰かが考えているものです。評価:C
以上、この話はおしまい。二度と蒸し返さないように。
Fランや専門学校は荒れてるわけじゃなく覇気がない
という意見をここ最近見るようになった
それで思うのが情報系の学部なんだよね
俺ら35歳くらいのオッサン世代は
情報系のやつらってべつにパソコンが得意だったから選んだわけじゃなく、しいて言うならパソコンくらいしか趣味がないみたいな連中が情報系に行くんだよね
機械系とかは車大好き！みたいなやつらが多いイメージなんだけど、情報系は覇気がない
だから起業なんて情報系のやつらはしない
その結果、三木谷もホリエモンも孫正義も、サイバーの藤田も南場智子も情報系ではないし、前澤は高卒だし
こういうやる気のあるやつに負けるんだよね
日本は小中高でろくに情報系の教育をしないから、不本意的に情報系にたどり着いたチー牛タイプの独壇場になってしまった
陽キャなやつらは情報以外に行ってしまうので、情報系がチー牛のブルーオーシャンになってしまった
GIGAスクールで陽キャなやつらに情報科目に触れさせ、パソコン面白いじゃんと思わせて情報系に進学させてほしい
いい意味で情報系がレッドオーシャンになってチー牛な学生が情報系からはじかれて
覇気のある学生が情報系に来てほしいと思う
たまたまお仕事の断り方という記事を読んだ。ひとり会社を経営してもうすぐ5年が経とうとしている。うちの会社では過去に1度、大きな失敗を経験してふりかえりを行った。その際に引き受けないお仕事の基準というものを社内で作成した。その失敗に至った原因の1つとして、本来引き受けるべきではないお仕事を受けてしまったと後になって反省した。
報酬が魅力的でも信用できない相手や嫌いな相手との取引
入金が遅い取引
自分のスキルアップにならない取引 (単純作業)
価格的に不利な取引
在庫などでこちらがリスクを負う取引
現金の出し入れや現金売上があがる取引 (手間が増える)
一般的に逆に思えるかもしれないが、本当の意味でお仕事は選ばなければいくらでもある。なんらかの理由で急ぎで運転資金や生活費を稼ぐ必要があり、仕事の内容を精査できない状況はあるかもしれない。それは向こうから依頼がくるのではなく、自らがそのお仕事を選択しているので別に構わない。
それは零細企業ほど他社のお手伝いにさけるリソースが小さく、それをいっときの雰囲気で判断してしまうと、中長期でみてうまくいかないことがある。むしろ、そのお仕事が失敗したとしても、自社にとっての収穫や価値があることを慎重に選ばないといけない。先の当社の失敗経験でいえば、結果的に2ヶ月ただ働きしたこととなり、何も得られるモノはなかった。
管理職になって初めて気づくこと
１．命令で人は動かない
２．厳しくすると嫌われる
３．優しくするとナメられる
４．優秀な人ほど、早く去っていく
５．部下に尽くすのは当然だと思われている
江崎グリコは5月1日、システム障害によって出荷業務を停止しているチルド食品について、停止期間が延びると発表した。これまで5月中旬の再開を目指していたが、1日時点で再開時期は「未確定」という。
あらー...
損害賠償金はどのぐらい行くだろうか
Fedoraプロジェクトは4月28日、インメモリデータベース「Redis」の代替としてRedisフォーク「Valkey」へのリプレースを検討していることを明らかにした。提案が承認されれば、今秋リリース予定の「Fedora Linux 41」ではRedisではなくValkeyがパッケージとして含まれることになる。
Valkeyへの変更を提案したJonathan Wright（AlmaLinux インフラチーム リード）はプロポーザルで「Redisのライセンス変更はFree & Open Source Software（FOSS）の原則と互換性がなく、FedoraのFOSSへの取り組みに影響を与える可能性がある。RedisのフォークであるValkeyはFOSS互換ライセンスを保持しており、強力なコミュニティと開発サポートが存在するため、Redisの有力な代替手段となりうる。（Valkeyであれば）ライセンス制限を損なうことなく、強力なインメモリストアをユーザに提供し続けることが可能だ」と指摘し、Fedora 41ではRedisユーザに対して「valkey-compat」互換パッケージを提供し、透過的なRedis→Valkeyへの切り替えを提供するとしている。この提案を受け、Fedoraプロジェクトの最高意思決定機関であるFESCoは、Wrightが現在進めている互換パッケージの作業の完了を待ってから再検討するとしており、5月中旬に再びミーティングを行ってから投票で決定することになる。
金子さんが考案したED法の興奮性・抑制性ニューロンのアイデアを誤差逆伝播法に適用することで、学習速度と安定性が向上することがわかりました、特にELUとの性能比較により、興奮性と抑制性のニューロンが存在することのメリットが明確にあらわれています。
1999年の時点で気づかれていた金子さんの先見性には本当に感服するばかりです。
研究が進んでいる
令和6年度はガバメントクラウドへの早期移行団体検証事業へ申込された、またはこれから申込予定の地方自治体様が多くおられると予想します。それに合わせて必要なAWSリソース利用料やAWSの設計構築・運用保守費用の見積・予算取りを進めることになります。
気を付けたいのが、ガバメントクラウドAWS「以外」にも必要となる設備・作業があることです。プロジェクトを開始しても、準備不足により作業がストップしたり予算不足になる事態は避けたいところです。
米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に基づいていると記述することはできる。