EUは他人の足を引っ張ることで優位性を確保する戦略を採っているのだろうか？ それにしては成果らしい成果は出ていないように見えるのだが。
オブジェクト指向プログラミングはCPUに優しくないです。
データ指向プログラミングがパフォーマンス問題への解法の一つになります。
メッセージパッシングはオブジェクト指向の基本パーツです。そしてメモリ配置はいじれない言語が多いです。
つまり、高級オブジェクト指向言語は CPUに優しくない のです。
ではどうすればCPUに優しいプログラムになるのか。
ここではパラダイムの変換による根本的な解決法を提示します。
それがData Oriented Programmingです。(!= Data Driven Programming!)
さて、これがどんな影響を及ぼすのでしょうか。tmlibのアクセスが遅かった理由を考えてみましょう。
そうです、間接参照を何度も行うことで、キャッシュミスが起きたことですね。
では、DOPではどうなるのでしょうか。
DOPでは、加工関数に対して、データが直列に並んでいます。逐次アクセスです。さらに、加工関数に対して、必要最小限のデータを渡すわけです。結果、キャッシュミスはOOPに比べておきにくいです。
DOPが威力を発揮するのは、同一データに同一処理を行う場合です。例えばゲームですと、画面上に現れる移動体には、位置、姿勢、生死etc...同一のデータが大量にあります。さらに画面更新毎に実行される訳です。
まさに適任です。
ですが、画面上のUIに関しては勝手が違います。例えばボタン、OKボタンとCancelボタンは押した際の挙動が違います。似たデータですが、同一処理ではありません。ボタンという概念が、他の概念を呼び出すわけです。これはオブジェクト指向のメッセージパッシングと同じ、よって この場合、OOPが適切です。
ゲームエンジン開発を行う上で重要な考え方にデータ指向設計 (Data Oriented Design) というものがあります。今回はこのデータ指向設計を例を交えながら紹介させていただきます。
データ指向設計は、その名の通りデータに着目した設計思想です。プログラムがやることは、データを入力にとって、何らかのデータを出力することです。データ指向設計では、そのデータをどのようにメモリに配置し、どのように読み込み、どのように書きだすのかに着目して設計を行います。
データ指向設計では主に次のようなことを行います。
- データのアクセスパターンを設計する
- データのアクセスパターンに応じてメモリレイアウトを設計する
さらに以下の点も考慮します。
- 複数のインスタンスを同時に処理するように設計する
これは複数のインスタンスを同時に処理するほうが最適化しやすいからです。
UserテーブルのID列はidかuser_idにするか悩む
ほかのテーブルとカラム名完全一致するのが楽なんもわかるしUserの持っているIDなのだからuser_がついてしまうと冗長なのもわかる
本来的にはuser_idであるべき派ですけど、フレームワークの都合でidにせざるを得ないことが多い…
テーブル名がネームスペースとして機能するからそこで表現できるのをカラム名にもつけるのは冗長だというのがid派の主張だと思うんですが、リレーショナル演算の最たる操作として結合や射影がありカラム（数学的には"項"）はそれ単体で自分が何者かを表現しきれないといけないと思ってるのですよね。
RDBを使っている理由がリレーショナルモデル以外の理由であり実態はオブジェクトである（≒必ず各行をオブジェクトにマッピングして使う）という感じであれば確かにテーブル名をネームスペースとみなしていい気もする。
完全にサロゲートキーならSELECTに出てこないのでいいけど、わりと id 付きで as user_id とかしてレポート出さないといけないことが多くて、それ実質連番管理があっち側ってだけのナチュラルキーじゃんって思いますね
けどまあ、言い出したら、ぜんぶの名前を user_name と company_name とかにしないといけなくて、それもさすがにuser_created_at と company_created_at なんかまでいくと、俺は何をやってるんだってなってきます
技術革新によってAI向けのチップの消費電力も低下するだろうか？
メインフレームを知らない世代なので、ほぇーという感想しかなかった
BlueskyはATプロトコルとよばれるSNSのためのオープンプロトコル上で動いているのですが、このATプロトコルは公開されており、それを使えばBlueskyのようなSNSを自分で設計することもできます。そして、そのフィードのアルゴリズムも自分たちで選択することさえできるようになるのです。
そして、同じATプロトコル動いているSNSであれば、別のSNSにも同じIDでユーザーとして参加できることを目指してATプロトコルはその標準化を目指しています。
ActivityPubとはまた別の標準を作るのか
C10K問題、一瞬話題になったけどその直後位にAWS（EC2）がサービス開始されて「まぁ、札束で殴ればいいよね」という結論に落ち着いてしまった印象がある。
自動車部品メーカーの株式会社東海理化は、業界初を謳う無接点磁気検知方式スイッチを採用したロープロファイルゲーミングキーボード「ZENAIM KEYBOARD」を5月に発売する。
独自に開発した無接点磁気検知方式キースイッチ「ZENAIM KEY SWITCH」を搭載するのが大きな特徴。自動車部品でも用いられる磁気センシング技術を応用し、磁気の変化をセンサーで読み取って入力を検出する。アクチュエーションポイント可変機能にも対応し、0.1mm単位で調節できる。
気になる。
配列は正式発表されていないけど、写真を見る限りフルキーボードなのかしら。テンキーレスもラインナップされるとよいのだが。
お値段は不明だけど、REALFORCEぐらいになりそうな予感はある。
公式Twitterに製品イメージがアップされた。どうやらテンキーレスのようだ。
MariaDB.com（開発主体の企業）が内紛で爆発四散してしまったという内部リーク？ らしい。
創業者や開発者は最早MariaDB.comにはいなくなってしまったとのこと。
MariaDBの今後はどうなってしまうのだろうか。
MariaDB自体はオープンソースなのでプロダクトは残るだろうが、フルタイムの開発者やサポートチームがいなくなれば採用に二の足を踏むプロジェクトは多いだろう。
案外AWSがまるっと買収しそうな気もしなくはないが。
Hacker Newsでは情報の正確性に疑問が呈されているようだ（唐突に差し込まれる差別反対の文言が胡散臭い、など）。
上記の発表資料とおなじく、スクラム導入して低コスト高リターンの課題を倒し終えた開発チームが「もうスクラムで成長できることはないし、スクラムなんてなしでよくね？」と言い出したりあるいは「オレたちのスクラムは完成した」「オレたち流でスクラムをカスタムしていこう」と言い出す。
そうして成長が止まったりアンチパターンにどハマりしたりする状態を指します。
いちいち「低コスト高リターンの課題を倒し尽くして停滞した「高原(プラトー)」のフェーズで停滞してしまうスクラム」というと長いので、ここでは プラトースクラム と呼びましょう
プラトースクラムで重要な点は「パッと見はスクラムとして機能しているように見える」にもかかわらず、スクラムに必須の重要なプラクティスを機能不全に陥らせます。
それどころかスクラムに最重要な開発チームが自律的な計画を立てられるようになる点を阻害し、マインドセットを社内受託へと歪めていきます。
誰にも悪意がないとしても、プラトースクラムは本来のスクラムに移行するためには有害なのです。
もう１つ重要な点があります。
プラトースクラムは変更不能な固定的な上位計画に支配されています。
固定的な上位計画という時点で分かる通り、古めかしいウォーターフォール的な考え方に基づくものです。
新規開発フェーズが終わった（保守運用フェーズに入った）プロダクトならプラトースクラムでもいいんじゃね？ 感ある。
スクラム開発最高！ ウォーターフォールはクソ！ みたいな固定観念を感じるのも胡散臭い。
努力！ 成長！ 技術的負債！ なアドレナリンジャンキーばかりを集めてしまうのも逆にリスクではある。
しかし、Goにはこのようなテスト関数ごとに暗黙的に実行される初期化処理を定義できません。Goが他言語に劣っているようにもみえますが、本当にそうなのでしょうか？ 公式のFAQにもあるように、とある機能がないことには何かしらの理由があるようです。
簡単に意訳すると、「10個のテストのうち9個のみが初期化処理を必要とすることもあるため、暗黙的ではなく明示的に書くべき」「暗黙的な実行は時間の経過とともに複雑さを増すことになるため明示的でシンプルであるべき」と主張しています。
ChatGPTを巡る言説で、どうも
①人間には「真の理解」とやらがあるという人々
②所詮AIはAI、人間には追いつけないぜ
という人々があぶり出されたなあと思う。
現時点で課題が山積みなのはそうだけど、マルチモーダルLLMの論文とか既に出てる辺り考えると、そこまで楽観視してられるかどうか。
「真の○○」みたいな当人にも定義できないなんかスゴイ概念で反論してくる奴は相手にする価値が無いってそれずっと言われてるから
この記事の中には、元IDEO社のデザイナー、George Ayeのストーリーが語られています。彼は現在、NPOの仕事しかしていません。新たな知識やアイディアを提供するのではなく、顧客が既に持っているアイディアを、いかにより良いものにしていくかを考え、必要なリソースを得たり、関係各所との調整を支援します。そして、プロジェクトがうまく行くのを見届けて静かに立ち去ります。現場にいる人が舞台の中央に立っていなければ、それは “profit-centered design” に過ぎない、と彼は言っているそうです。
この考え方は、デザイン思考に限らず、コンサルティング会社など専門知識を支援するビジネス全般にあてはまるのかもしれません。心に留めておきたいと思います。
MIXI傘下のMIXI RECRUITMENTは4月3日、同社が手掛けるIT・Web業界に特化した求人・転職サイト「FINDJOB!」を、2023年9月に終了すると発表した。
FINDJOB終了するのか
情報処理推進機構（IPA）の公式Webサイトリニューアルについて、Twitter上で批判の声が上がっている。新URLへのリダイレクト設定がなく既存のリンクを開いても「404 Not Found」になっているとの報告が相次いでいる他、RSSがなくなって困るというユーザーもいる。
CMSが変わる度にURL体系がガラッと変わってしまうの悲しいけどあるある。
そういう事があるので、WEBサイトのURLは単語やSlagなどでオシャレな感じにはせず、最低限の階層（ディレクトリ）を切った上で連番のURLを与えるべきだと考えている（つまりこのサイトのようなURL体系）。
コンテンツに対して機械的に連番を付与する方式はユーザービリティの観点では微妙に難点があるが、頑健性の面で非常に優れている。
2. 原因について
コンビニエンスストアで証明書交付申請をされる方が増加し、取引負荷が高まったため、印刷処理における遅延が発生いたしました。この遅延に起因し、システム上設定されていたタイムアウトの上限を超える状態となり強制的な印刷処理の解除が生じ、次の印刷イメージファイルを誤って取得したため、申請された方とは異なる住民の方の証明書が発行されました。
負荷が高まり処理がタイムアウトすると印刷処理を解除する → しかし、印刷イメージファイルは削除されないままキューに残る → 次のプロセスがキューの一番上に残されているイメージを取得＆印刷 → インシデント！ って感じなのだろうか？
これは負荷テスト以前に異常系の設計がお粗末過ぎる気がするのだが。
住民票の取得を管理するシステムと印刷を制御するシステムと印刷キューを管理するシステムの協調動作が必要とは言え、印刷が失敗した場合の後始末は負荷が高低に関わらず行われなければならないはず。
しかし、そうなっていないという事はコンビニのプリンタからの印刷ステータスの通知を受け付けるAPIも印刷システムと同じサーバに載せていたので、仲良く処理が止まっていたみたいな状態だったのだろうか。
コンビニの証明書交付サービスで別人の住民票が発行されるトラブルが横浜市で発生した問題について、サービスの提供ベンダーが富士通Japanであることが日経クロステックの取材で2023年3月29日までに分かった。同社が手掛ける証明書交付サービスへのアクセスが集中し負荷が高くなったことで、「プログラム的な瑕疵（かし）が表面化した」（広報）という。
ひぇっ...
このモデルの作成に使ったデータの大元（Alpacaデータ）はText-davinci-003というOpenAIサービスで出力した結果になりますが、OpenAIの利用規約ではコンテンツ生成者はOpenAIサービスで出力した結果を競合モデルの開発用途に使用してはならないと記載されています。ただ、コンテンツ生成者以外の第三者には利用規約は適用されないため、第三者が出力結果を競合モデルの開発用途に使用することは可能であり、今回私が利用したAlpacaデータも私がモデル開発に使用することは可能です。ただし、法的に問題ないとしても倫理的には問題があると思っており、仮に企業が堂々とAlpacaデータをモデル開発に使うのであれば多少のレピテーションリスクが発生すると思っています。タイムリーですが、Googleの開発したLLMのBardが実はChatGPTの出力結果を知識蒸留で使っていることが判明し批判を受けていたりすることを見ても企業が使用するとリスクを伴うのは間違いないと思います。
前述した通り、Alpacaデータを用いると多少のリスクが伴います。そのため、何の懸念もなく商用モデルの開発に使用できるクリーンなデータセットを作りたいと考えました。そこで今回、GPT-4を利用できるアプリを無料で公開し、そのアプリで収集したデータを活用してクリーンデータを作成することにいたしました。
おぉー
libSQLを使ったDB as Serviceって感じだろうか
2022年9月開催の「GTC September 2022」で発表されたJetson Orin Nanoは、AI処理性能が275TOPS（1TOPSは毎秒1兆回の演算性能）に達する「Jetson AGX Orin」と同じAmpereアーキテクチャを採用した“Orin世代”の製品となる。これまで、最大275TOPSのJetson AGX Orin、最大100TOPSの「Jetson Orin NX」が発表されていたが、より安価なエントリークラス製品として設定されたのが最大40TOPSのJetson Orin Nanoとなる。
これまで「Jetsonシリーズ」のエントリークラス製品と言えば、99米ドルと安価にAIモジュールの性能を試せる「Jetson Nano」が知られている。Jetson Orin Nanoは、AI処理性能20TOPSのメモリ容量4GBモデルと、40TOPSの8GBモデルがあり、価格はそれぞれ199米ドル、299米ドルとなっている。Jetson Nanoと比べて価格は2～3倍になったものの、AI処理性能は40～80倍に向上している。
Jetson Nanoをはるかに上回るJetson Orin NanoのAI処理性能の活用法としては、ジェネレーティブAIとして急速に活用が広がりつつある「ChatGPT」にも用いられたトランスフォーマーモデルをエッジデバイスで動作可能な点に注目が集まっている。取り扱うパラメーターの多さから、トランスフォーマーモデルはクラウド上での動作が前提とされているが、Jetson Orin Nano開発者キットを活用すればエッジデバイスにおけるトランスフォーマーモデルの活用を検討できるようになるという。
エッジでGPTが動かせるのも面白いけど、とりあえずローカルでGPTを動かす母艦にできると色々助かる。
優れたドキュメントには、大きく二つの特徴があります。
一つは、ユーザー（ドキュメントを使う人）の課題解決につながる内容であることです。
（中略）
また、優れたドキュメントの二つ目の特徴は、「生きている」ということ。つまり、常に最新の状態が保たれたドキュメントであるということです。
世の中には「コードを見れば全部分わかるでしょ」といったストロングスタイルな開発者も存在しますが、今回翻訳した書籍の中ではむしろ失敗パターンとして挙げられています。名著である『A Philosophy of Software Design』の中では、そうした考え方は「神話」だと一刀両断されています。
Simple vs Easy という話がどこまで共通認識になっているのかは分からないが、 React に比べて Elm は圧倒的に「シンプル」側に倒した設計になっている。個人的に考えるシンプルさのメリットは以下のようなものだ。
- コードを見れば何が起きているか分かる
- 覚えなければいけない特別なルールが少ない
- 予想外の挙動が起きにくい
ただし、これらのメリットによって喜ぶ程度は、かなり人によりバラツキが大きいように思う。ぶっちゃけ、シンプルで美しいからと言って機能性の乏しさを我慢できるのはオタクだけなのではないかと思ったりする。実際、ボイラープレートが多いのは客観的に見ても面倒だと思っており、「シンプルさのために多少の面倒は我慢しなさいよ」と言うのは乱暴だろう。
しかし、考えてみれば古来から言われてきた Model と View の分離、 React も是としている「ビューは純粋な関数」を何よりも体現できているのが、この Elm Architecture であると思う。ある種の完成された形として後世に受け継いでいきたい。
GPTでAI界隈が沸騰している。開発者も含めて誰も急激な性能向上の理由を理解出来ていない。普段は半年や1年で古くなるような時事ネタはあまり呟かないことにしているが、このところの動きがあまりに早く、未来に向けての不確実性が高まっているので、少し現時点でのシナリオ整理をしたい。(1/15)
まず、現状を整理する。最近の成果はそのほとんどがトランスフォーマーと呼ばれるエンコーダ・デコーダモデルによる。注目すべきはこれが畳み込みや再帰といった並列計算を防げる仕組みを廃したために計算力の集約が可能になり、飛躍的に大規模なデータセットでの学習が可能になった事だ。(2/15)
そこで起きたことが、スケーリング則の発見だ(2020年)。 (https://t.co/xmI6nbGNNl) つまり、計算量、データサイズ、モデルの規模の３つを同時に大きくしてゆくことで、あたかも上限なくモデルの性能が上がってゆくように見える現象だ。(3/15)
さらに2022年になって、10の23乗から24乗回あたりの計算量を境に急激に性能が向上するという現象が確認された。ある程度予測可能なスケーリング則から非連続的なテイクオフに移行したように見えるため、今後何が起きるのかが見えにくくなっている(https://t.co/Qy96aMCs8E)。 (4/15)
そこで一旦基本に戻る。機械学習モデルが出来るのは学習に使ったデータからの帰納だ（既に見たことがあることしか予測出来ない）。しかしGPT3/4は柔軟な応答や多段論法など一見学習データセットから直接的に導けるとは思えない演繹的なタスクを実行しているように見える。可能な説明は二つある。(5/15)
１つ目は我々がこれまで演繹と思っていたものの大部分が帰納だったという可能性だ。例えばシマウマと聞いて縞模様のあるウマを想起するとき、ある特徴とあるモノとを組み合わせて別のモノを導き出すこれと同型のパターンはデータセットのどこかに含まれていた。(6/15)
おそらく10の24乗FLOPSというのは人類が言語情報の形で蓄積した知識の総体から意味ネットワークを抽出するのに必要な計算量なのだろう。丁度その辺りの閾値を超え急激に意味ネットワークがつながり性能が向上した。この場合今後はシグモイド的（急激な上昇の後に停滞期が来る）に推移するだろう。(7/15
２つ目の可能性は、北川さん(@takuyakitagawa)やgoogleのブログにあるように、ネットワークモデルに創発的（相転移的）な現象が起きているということだ。つまり、計算力の適用によりデータセットには明示的に含まれていない新しい連関や意味ネットワークが生まれているという可能性だ。(8/15)
数学で公理系から様々な定理や命題が生み出されるように、言語データに含まれる情報から新しい情報が生み出される。人類の頭脳がその一部しか探索してこなかったなら今後AIがもっと深くて広い知的探索を担うかもしれないシナリオだ。言語システム自体が演繹性を持つ可能性とも言える。(9/15)
これらのどちらなのかは、あと数ヶ月から１、２年くらいで明らかになるかもしれない。(10/15)
もし１つ目の可能性が正しい場合、計算量とモデル規模の伸びに対していずれ学習データ量が追従出来なくなり、「人類がこれまで言語その他の情報の形で書き溜めた知識の総体」を学習し切ったところで性能向上は頭打ちになるだろう。(11/15)
２つ目の可能性が正しい場合には、当面は際限なく性能が向上するように見えるだろう。その場合、計算力に関する物理的な制約がクリティカルになることは何度か紹介している私の2018年の論文でシナリオ整理している通り( https://t.co/Lz2OdXsr8k )。(12/15)
現在の言語モデルベースのAIは能動性や身体性が欠けている点で限界があるが、機械学習モデルにツールやセンサーを使いこなさせるための仕組み（認知アーキテキチャ）の研究は様々なところで取り組まれている。(13/15)
ロボットやネットツールなどを使って能動学習を行うAIの開発に根本的な技術上の壁はないので、そうなれば理論上は「人類のこれまでの知識の総体」を上限とする理由が無くなり、物理現象の時定数 のみが制限として残る(上記論文参照)。このあたりがさらに先を見たシナリオ分岐に関係するだろう。(14/15)
余談) ちなみに、技術的にはあまり意味のない試算だが10の24乗FLOPsというのは人の脳を10の15乗FLOPs毎秒として１日8時間で90年分の思考にあたる。90年間ひたすらwikipediaやネット上の文章を読み続けた人がどれだけ博識かと想像すると直感的にはなんとなく理解できる閾値の規模だ。(15/15)
【概要】
2023年3月30日（木）にドコモが業務を委託している企業において、業務に使用しているパソコンから、個人向けインターネット接続サービス（ISP）「ぷらら」及び「ひかりTV」のお客さま情報が流出した可能性があることを確認いたしました。
（1）発生日時
2023年3月30日（木）13時40分ごろ
（2）流出した可能性がある件数
最大 約529万件
（3）流出した可能性があるお客さま情報
個人向けインターネット接続サービス（ISP）「ぷらら」及び「ひかりTV」のお客さま情報
氏名/住所/電話番号/メールアドレス/生年月日/フレッツ回線ID/お客さま番号
※クレジットカード情報及び金融機関口座情報などの決済関連情報は含まれておりません。
事象確認後、流出元と想定されるパソコンをネットワークから隔離いたしました。
現在も調査を継続しており、今後新たな情報が判明しましたら、随時公表してまいります。
なお、本件に関してご不安な点やご不明な点がございましたら、下記のお問い合わせ窓口までご連絡をお願いいたします
oh...
Freeは書き込み専用のプランで、価格は無料。APIのテストに使えるとしている。ツイートの書き込みは月間1500件まで。使えるTwitter IDは1個。Twitterログイン機能も利用できる。
Basicはホビーユーザー向けのプランで、価格は月額100ドル（約1万3265円）。サービスのプロトタイプ制作に使えるとしている。ツイートの書き込みは1ユーザーにつき月間3000件まで、1アプリにつき月間5万件まで。読み込みは月間1万件まで。
Enterpriseはビジネスや広告プロジェクト向けのプランで、価格は非公開。仕様はニーズに合わせて設定する。専任チームによるマネージドサービスも提供するとしている。
高過ぎワロタ
どっちかというとReadのAPIを無料で使いたいのだが。
みずほフィナンシャルグループ（FG）とLINEが共同で設立を目指してきた新銀行「LINEバンク」の開業を断念する方針を固めたことが29日、わかった。スマートフォン専業銀行で若者の取り込みを狙う新事業だったが、システム開発が難航し競争環境も大きく変化した。みずほにとってはデジタル戦略の仕切り直しになる。
両社は2018年11月にそれぞれ傘下のみずほ銀行とLINEフィナンシャルが共同出資し、新銀行を設立すると発表した。直近の準備会社への出資比率はみずほが66.6%、LINEが33.4%で、議決権比率は50%ずつ。当初は20年度の開業を目指していたが、22年度をめどに2年延期していた。
案の定、みずほ銀行擦られまくってて草
このBikal Electronicsに所属するSerge Seminという開発者が3月14日、Linuxカーネル開発者メーリングリスト「LKML.org」にBikalチップのドライバコードの修正を含む13のパッチを連投した。だが13番目のパッチを共有したあとにメンテナーのひとりであるJakub Kicinski（Meta所属）から返ってきたのは、それらのパッチに対する短い、しかしはっきりとした拒絶であった。
我々はあなたが所属する組織（Bikal Electronics）が製造したハードウェアに関連したパッチを受け取ることに不安を覚えている。追って通知するまではネットワークへの貢献を控えてほしい。
We don't feel comfortable accepting patches from or relating to hardware produced by your organization. Please withhold networking contributions until further notice.
明らかにパッチの品質ではなく、開発者が所属する組織を問題視していることがうかがえる。
なお、このLKML.orgの対応に対して、ITニュースメディアの「The Register」は「ロシアのオープンソース開発者の貢献を拒絶することは、ロシアの国家や組織にダメージを与えるものではなく、ロシアが悪行を再考するきっかけにもならない」として「（LKML.orgは）時代遅れな対応」と厳しく批判している。
意図的な脆弱性やスパイウェアの混入のようなあからさまな妨害工作でないのであればパッチを受け入れてもよいと思うが、一方で「そうではない」事をカーネルメンテナが一々調査検討しなければならないのであれば、そのコストは負担できないという判断も妥当ではある。
コスト最適化の観点でNew Relic Infrastructureは使うのをやめ、Prometheusに寄せる形にしました。また、PrometheusからNew Relicに送るメトリクスは最小限にし、Amazon Managed Service for Prometheusに送るように変更しました。
以前の勤め先もDataDogのコスト増加に悩んでいたし、やっぱ全てのメトリクスを外部サービスに垂れ流しちゃいかんぽいな。
長期的に追跡したいメトリクスは運用コストを考えて外部サービス、短期的なメトリクス（アラート系）はセルフホスティングの監視系とするのが良いだろうか。
みんな、真面目に本を読みすぎてるのかもな。金と時間かけて読むからには隅々まで良い本であってほしいし、良いところを全て理解したいと思うのはわかるんだけど、まあ色々無理なので、雑に読むといいと思う。良いところを一箇所でも見つければそれでええ。
データ圧縮フォーマットのひとつであるZIP(ZIP圧縮)や、電子文書フォーマットのPDF、音声ファイルフォーマットのMP3の基礎となったデータ圧縮アルゴリズムのLZ77やLZ78などを開発したイスラエルのコンピューターサイエンティストであるジェイコブ・ジヴ氏が亡くなりました。91歳でした。
Cloud Native Computing Foundation（CNCF）のSandboxプロジェクトとして開発が進められているオープンソースのFaaSプラットフォーム「OpenFunction」がバージョン1.0の登場に合わせてWebAssemblyをサポートしたことが発表されました。
OpenFaaSはコードをコンテナイメージにビルドし、それをKubernetes上のランタイムでイベントドリブンに実行するなど、さまざまな機能が統合されたFaaS（Function as a Service）プラットフォームです。下記のように、多くのオープンソースソフトウェアによって構成されています。
Openfaasとはまた別のプロダクトなのか。
コンテナを実行するということはどちらかと言うとGCPのCloud RunやKnaitveに近い感じだろうか？
宗教において「悟り」とされていたものが、脳内のWorld Modelの次元数を増やすことだったとかになったら面白いな。
他に面白かったのは、「world modelが人間の脳には一つなので人間は意識して一つのreasoningやプラニングしか同時にできないのではないか。また、world modelが一つであるため、他のタスクの経験を別のタスクに活かせる。」
「world modelが一つであるため、他のタスクの経験を別のタスクに活かせる」というのは言い換えるとヒトは「体験したことにしか対応できない」、そして「成功体験に固執しやすい」ということなのだろう。でも、それは傾向であって原則ではない。
ヒトには「共感力」という妙な能力がある。他個体やヒトですらない動物・動物ですらない機械や創造上の架空存在にも「共感」して、その体験を自分自身に投影する能力がある。ヒト以外の動物にこの能力があるのかはよくわからない。仮にあったとしても、ヒトほど高くないだろうことは推測できる。
これが行き過ぎると「電波脳」になったり多重人格症になったりするけれど、大抵の人は共感力と折り合いを付けて生きている。AIが言語や感情らしきものを身につけたら、次の研究分野は「共感」になるのかもしれない。
「漫画家は体験したことしか描けない」って何度かバズって「んなことねぇぞ！」という反論が吹き荒れたけれど、ヒトが自ら体験していないことを創造でき、その創造作品を鑑賞できるのは「共感力」の作用だと僕は考えている。
AIが共感力を身につけたら、狭義のシンギュラリティが起きるかも知れない。それが人格を持ち自意識を持つ存在であることを否定できなくなりそうだ。
米Intelは24日、共同創業者の1人であるゴードン・ムーア氏が逝去したと発表した。享年94歳。
ムーア氏は、ロバート・ノイス氏ともに1968年にIntelを創業した人物。1975年に社長、1979年に会長兼最高経営責任者になった。同氏は「ムーアの法則」の提唱者としてもその名を知られる。氏は1965年に書いた論文で、「集積回路内のトランジスタの数は毎年2倍に増える」(Intelのプレスリリースより抜粋、翻訳)と予想。その後その内容は「ムーアの法則」として知られるようになり、Intelの新CPU開発の原動力ともなっている。
システム構築の複雑さから開発者を解放するデータ指向プログラミング実応用ストーリー
本書は Yehonathan Sharvit, "Data-Oriented Programming", Manning Publications 2022 の邦訳版です。
【本書の内容】
本書は、Java、C#、C++、Ruby、Pythonなどの高級プログラミング言語で2年以上の経験を持つ、フロントエンド、バックエンド、フルスタック開発者向けの本です。
本書で取り上げている業務システム開発におけるアイデアや手法は、オブジェクト指向プログラミングの開発者にとっては、慣れ親しんだ環境や世界観をいったん捨て去るように指示されるかもしれません。
一方、関数型プログラミングの開発者にとっては、本書は（多少ですが）学びやすく、ちょっとした発見とサプライズがあるはずです。
いずれにしても「情報システム開発の複雑さ」を軽減し、見通しが良く仕様変更にも柔軟に対応したい開発者に、新しい視座とパラダイムを提供します。
気になる。要は関数型プログラミングについての本なのだろうか ？
あ、わかった若者が所詮CRUDもどきの延長線の仕事でぐちぐちと構造！！とかドメイン駆動！！とかって叫ぶのってこの仕事が本質的に簡単だから自分の存在価値を発揮したいだけなんだな。腑に落ちた！
自分の理解が追い付かないものを見た時、人はそれを見下すことで認知的不協和を解決するものである。
「俺にしかできない」とイキってる人は、むしろ「自分にしかできない属人的な状態にしてしまった」と反省してください。自分にしかできない状態にしてしまったことで、いずれ自分で自分の首を絞めることになるけど、それでもまだ「過去の自分の過ち」と気付けない人は、社会から居場所がなくなります。
まったく自慢にならないことに早く気づいた方がいい。
ビルゲイツとかスティーブジョブズが言うならまだしも、最初から自分にしかできない特殊な能力や技術を要したわけじゃなく、怠慢さや無能さにより、他人には分からないぐらい複雑なものにしてしまっただけ。
ほんまこれ
スタディサプリのシステムアーキテクチャ
Raspberry Pi上で動かせる、GPT-3相当の大規模言語モデル（LLM）「Alpaca LoRA」がGitHub上で公開された。米MetaのLLM「LLaMA」の派生モデル「Stanford Alpaca」を再現できるという。
LLaMAは米Metaが独自開発した大規模言語モデル。LLM分野の研究推進を支援するため、研究者向けに2月にリリースした。大規模インフラを利用できない研究者のために小規模ながら性能の高いことが特徴で、7B（＝70億）、13B、33B、65Bの4種類のパラメーターを用意している。13Bモデルはベンチマークで米OpenAIのLLM「GPT-3」を上回るという。
米スタンフォード大学は、LLaMAの7Bモデルを派生させ独自のLLM「Stanford Alpaca」を開発。このモデルは研究や学術目的でのみ利用でき、娯楽や商用での利用は禁止している。Alpaca LoRAでは、Stanford Alpacaが生成するトークン（単語列）を再現できるという。
おぉー
動作速度はどんなものだろうか？
YYYY/MM/DD ADR Title
# Status
# Situation
# Context
# Material for decision
# Decision
# Consequences
Approval Tests というツールセットを使うと簡単に「Approval Testing（承認テスト）」を実装できる．Approval Testing では，スナップショットテストのように "結果全体を意識した" テストコードを記述する．GitHub には Golden master Verification Library とも書かれていて，BDD (Behavior-Driven Development) で使われることもある．
RISC-Vだとどんなメリットがあるんだろうか？
CPUのライセンス料が不要なのでコストが安くなる→製品の最終的な値段に影響するって感じか。
N=3の話だけど、アプリで知り合った大企業の女性に会った時に、自分の次の職場が企業のDX部門だと説明すると、そんな仕事は下請けに任せれば良いので、コストの無駄だと馬鹿にされ、その後ブロックされた。大企業の女性社員様からすると、ITエンジニアって下請けの格下男と認識されているみたい
彼女らに、システム内製化のメリットを色々と説明しても、ITやAIのエンジニアなど自分達総合職に比べたら格下であるとずっと馬鹿にされていたので、大企業でDX部門を立ち上げようとすると、本体から切り離して別会社にしないといけないんだなーと肌で実感した。
初めて出会った人の職業を面と向かって馬鹿にするってそもそも人としてヤバいなと思ったけど、大企業の女性社員様からしたら、DX部門の中途入社ITエンジニアなんて、新卒では大企業に総合職で入社できなかった格下なので、一緒に食事をするのも汚らわしいゴミなんだろうな
あと、AIやるって言ったら、自分の高度な仕事はAIなんかには代替されないと顔を真っ赤にして憤慨されたので、若い女性でも老害になるのだなと興味深かった。
人材派遣大手の某P社の女性がユニクロの無人レジが凄いと話していたので、それがDXなんですよと説明したら、でもDX部門にITエンジニアの人達が入ってきたのって最近でしょ？元々ユニクロは大きいのでその人達は何も関係ないですよねﾄﾞﾔｧと反論されて、顔面ぐーぱんしてやりたくなった。
もう一つ思い出した！
そのうちの1人に出身大学を聞いたら、四ツ谷周辺の大学ですってドヤ顔された笑笑
うーむ
Pythonコードをネイティブコードに変換するコンパイラだそうな。
10倍〜100倍の高速化が見込める模様。
フルマネージドKubernetesは使ってみたい。