さて、こういうOSSの状況にどう対処したらよいのかというのは難しい。
全部自身で実装する。 私自身は言語バンドルライブラリ以外は極力避けたい派で、自作プロダクトではこれを指向しているけれども、大規模なサービスやプロダクトでは現実的でないことも多いだろう（GoやNode.jsなどモダンな言語ではバンドルは最小限方向だし）。
サービス内容とOSSコンポーネントの役割を理解し、いざというときの代替を探しておく。 まぁこれは業務だったら当然考えてるよね（よね？）というところだけど。部品に限らず、スタートアップの速度重視からスケール対応重視のフェーズになっていったときにもう言語スタックから全部別ので作り直したほうがよいのでは、というケースもあるだろう。
OSSが継続できるようメンバーにジョインする。 死んだらforkで済ませればいいというのはまぁそうなんだろうけど、中の人になっておいたほうが様子はわかるし、活動していればOSSの中身自体の理解も進む。昔は必死にひどい英語モドキでやりとりするしかなくて「お前が何を言っているかわからない」という返答に枕を濡らしていたけれども、今はGoogle翻訳もDeepLもあって最高（あと、そもそも若手皆さん英語できるね……）。いずれにせよ、「全部実装」よりは軽いのではないか。
OSSを支援する。 ジョインはちょっと重いなーというときには、あとはなんとかOSSが死なないように支援する。対処できることはOSSが死ぬケースのうちのごく一部にはなるけどね。理由が金銭的困窮であればGitHub Sponsors、あるいは商業ライセンス購入（デュアルライセンスが用意されていればやりやすい）などが考えられるか。個人的には開発者会議の会場スポンサーは援助としてありがたかった。
研究者はDockerイメージを分析し、2万8,621個のDockerイメージから5万2,107個の秘密鍵と3,158個のAPIキーを発見したとしている。見つかったこれら鍵のうち、秘密鍵の95%およびAPIキーの90%はシングルユーザーイメージに存在しており、意図せずに流出した可能性が高いことことが指摘されている。
Docker HubにはDockerコミュニテイによって作成されたDockerイメージが保存されており、共有および配布などに使われている。Dockerは手軽に必要な環境を用意することができ、開発や運用において活用されている。こうしたDockerのイメージにパスワードや秘密鍵、APIキーといった機密情報が含まれてしまっていることは以前から指摘されており、今回の研究もこの指摘を裏付ける内容になっている。
Dockerイメージに含まれている秘密鍵やAPIキーがサイバー攻撃者によって悪用されている危険性が指摘されており注意が必要。Docker HubなどにDockerイメージを登録したり、または、こうした場所から取得したDockerイメージを使ったりする場合は、鍵が含まれていないか確認するとともに、鍵が含まれている場合には登録の削除や使用の停止など、適切な対応を取ることが望まれる。
DockerとDocker Hubが密結合になってるのでうっかりイメージをアップロードする事故は起きてるだろうなとは思っていた。
まぁ、手抜きしてAPIキーや秘密鍵を封入したイメージ作るのが悪いというのはあるんだけども。
サーバーとクライアントで言語統一できるとドメインモデルが共有できるといわれる。まぁ確かにゼロではないね。とはいえ、そもそも担当する責任や解決する課題が違うので共有できるものは限定的で、あるとしたらインフラストラクチャのロジックの方が共有できるんではないかと思う
逆に共通したい部分って突き詰めるとテンプレートの（再）展開ロジックだけなんですよね
やっぱそうなるのね…
この視点は生成AI、大規模言語モデルの基礎なんだけど、AI持ち上げの方々はすっかり忘れちゃって「AIすげ〜、AI便利〜」ってなる。昔の人工無脳ＥＬＩＺＡと同じ反応。今のAIは、次の単語予測してるだけ、意味はわかってない、記号の現実的基礎を固める記号接地はない、ってこと覚えておきたいですね。
「相手の要求をわかっているように振る舞う、それがものすごくうまい機械」とチャットGPTを語る今井むつみ慶大教授。対話型ＡＩはデータの統計的規則性を抽出し、この言葉の後にはこの言葉がふさわしいという情報処理をしながら文章を作る。一言でいえば 次の単語予測機だと。
端的に言うと、少なくともここ１年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。
ソフトウェアエンジニアがほぼいない組織、あるいは集計・分析用のDBが分かれていてそこからデータを読み取る用途（レコードの更新によってエンドユーザーに対して甚大な影響を及ぼす危険性がない場合）に限定して言えば、基本誰でも触って良いケースが多いです。 誤ってスロークエリを発火させない限りは強力な業務効率化が望めるため”民主化”が概ね歓迎されると言えます。
逆に、ソフトウェアエンジニアが大きな割合を占める組織や、データを更新・作成する用途だと、誰でも開発を分担できてしまうと統制面で問題になることもあります。
統制面で問題になるのは、具体的には成果物のメンテナンス責任とアクセス権限の管理責任の２つの観点です。
非エンジニアがノーコード・ローコードによってUI上で設定をしても、運用に乗ってからメンテする責任がエンジニア側に寄ってしまう場合、ブラックボックス化されたシステムの面倒を見ることになります。
当然、初期のレビューを誰も通さず、今後も中身がわからない（あるいは大してhuman-readableではないJSONなどの中間表現でしか出力できない）ツールだった場合、メンテ責任がエンジニアによってしまうケースだと途中から体験が悪化してしまうでしょう。
また、アクセス権限の管理責任にも問題が生じます。誰でもシステムのたたき台を作れて良いとしても、誰でも好きなデータにアクセス、更新して良いわけではありません。
やはり通常は権限体系を整理した上でないと、ソーシャルエンジニアリングや人為的なミスを誘発するおそれがあります。
そうした事象の回避のためにも、権限体系の設計やミスが少ない画面遷移の設計に技術的に知見のある人間が責任を持たないと、不安が生じます。
これは海外のデベロッパーツール界隈でも同様に起きている事象ですが、私見でいうと彼らはこの問題を、想定利用者を非エンジニアではなくエンジニアに全振りすることで解決しようとしているように見受けられます。
ビデオカードのメモリが増設できない理由について、昔この業界に関わったことがある俺が説明してみる。理由は2つで、技術的ハードルが高い点と需要が無いという点である。
■ その1 技術的ハードルについて
現在主流となっているビデオカードのメモリはGDDR6という規格である。こいつは16Gbpsでデータを転送できるんだが、1bitのデータのやりとりに使えるのはわずか62.5ピコ秒しかないということだ。これってメチャクチャやばい話で、僅か数mmの配線長の違いでも信号のタイミングのずれに影響してしまう。PC系のニュースサイトでビデオカードからクーラーを外した写真がよく掲載されているので試しに見てほしいのだが、タイミングずれが起きないようにGPUの周りを囲むように等距離になる位置にメモリが配置されているのがわかるだろうか？また、このような配置には、配線距離が短くなるメリットもあるのだ。
一方、PCに使われるメモリモジュールだが、見てわかるように長方形の基板にメモリチップが載せられている。配線の距離は当然ビデオカード直付けのものと比べて長い。各メモリチップ間の配線長のチップ間差だけならどうにかできなくはないが、配線長の絶対的な長さが問題になってくる。モジュール上の数センチの配線で生じる配線抵抗と寄生容量の影響がかなり大きく、1bitのデータをわずか62.5ピコ秒で転送しなくてはならないビデオカード向けメモリだと致命傷になってしまうのだ。
余談だが、数年前にGDDR5Mというモジュールでメモリを増設できるビデオカードむけのメモリ規格が提案されたことがあったのだが、上記のような問題から当時主流であったビデオカードに直付けするタイプのGDDR5に比べて性能が低く(7GbpsのGDDR5に対し5Gbpsにとどまった)、その程度なら3.2Gbpsでデータを転送できる汎用のDDR4と比べて大したメリット無いじゃんということで製品化されずに終わってしまった。
■ その2 需要の無さ
あなたは世界で一番ビデオカード向けのメモリを買っているメーカーがどこかご存じだろうか？実はソニーである。ちなみにナンバー2はマイクロソフト。何を隠そうビデオカード向けのメモリの需要って大半がゲーム機向けなのだ。ゲーム機の場合、世代交代するまでの5年間くらいは基本的にスペック固定である。なのでメモリの増設需要がそもそもない。そしてゲーム機の市場規模自体が他の電子機器に比べると一桁二桁小さい。
例を上げると、スマートフォンの年間販売台数は全世界で12-3億台。PCでざっくり3億台。ゲーム機は年間1000-2000万台。ビデオカード向けメモリの最大消費者のゲーム機でさえ、スマートフォンの1/50の市場規模で、それより小さいPC向けビデオカード市場で、さらにメモリを増やしたい人向けの市場規模となると察して下さいとしか言いようがないレベルになる。その僅かな市場に何億もの開発費をかけて製品を出そう！という酔狂なメーカーはなかなか出てこないだろう。
最も、スーパーコンピュータのような特殊な用途だと増設できるGPU向けメモリが登場する可能性があるかもしれない。数年前に不祥事を起こしたスーパーコンピューターベンチャーP社の例だが、10年ほど前に倒産したメモリメーカーE社の元エンジニアを集めてカスタムメモリを独自開発しようとしていた節がある。絶対的な性能やどうしても大量のメモリがないと困るというシチュエーションがあれば、経済的合理性ガン無視で独自規格の製品を作るモチベーションが生まれるというわけである。
2023年4月9日、新潟県の内部業務で使う公文書ファイル約10万件が消失した。定期メンテナンスで不要ファイルを削除した際、必要なファイルも削除された。引き金は、保守運用事業者の富士電機ITソリューションが追加した新機能。同社の運用担当者も県担当者も新機能追加を知らなかったため対応が遅れ、バックアップデータも消失していた。
有料会員では無いので2ページ目は見れないけど、何か新情報は判明したのかな？
これについて、ソーシャルニュースサイトのHacker News上では「Firefoxの方がChromium(ベースのブラウザ)よりもはるかに遅く感じる時期がありましたが、ここ数年はFirefoxの方が遅いにしてもほとんど気にならない程度の差になってきていると感じていました。遅いのにFirefoxを利用する理由は、明らかに優れた機能や高負荷でも優れたパフォーマンスを提供できるブラウザだからです。しかし、今回のベンチマーク結果でChromiumがFirefoxよりも優れているという幻想は過去のものとなってしまいました」のような、これまでFirefoxを利用してきたユーザーからの歓喜のコメントが寄せられていました。
また、特定の拡張機能を利用するためにFirefoxを利用しているユーザーの「Chromeの速度が遅いので、数年前にChromeからFirefoxに乗り換えました。特に多くのタブを開いている場合、Chromeでタブを切り替えると真っ白な画面が2秒間ほど表示されることがあります。私がFirefoxを使い続けているのは、パフォーマンスではなく拡張機能のTree Style Tabのためでした。この拡張機能なしで10個以上のタブを開くことは想像できませんでした」といったコメントや、Firefoxのセキュリティに信頼を寄せるユーザーからの「コンテナやパスワード保存機能があるためFirefoxを利用し続けてきました。たまにChromeを利用しなければいけない時、パスワードの自動入力が拒否されて疲れ果ててしまいます」といったコメントもありました。
やったぜ
米Metaは7月18日（米国時間）、大規模言語モデル（LLM）「Llama 2」をオープンソースとし、研究および商用向けに無償での提供を開始した。Llama 2のウェブサイトからモデルをダウンロードできる。
2023年3月に発表された「Llama 1」の新バージョン。提供されるモデルはパラメーター数が70億／130億／700億（7B/13B/70B）の3種類あり、事前学習済みのバージョン、チャット用にファインチューニングしたバージョンがある。
COBOL案件と同じで、少ないながらも需要があって、納期通りに納品できるなら重宝される分野というのはあるという話だ。
大規模システムの設計を学ぶ
スケーラブルなシステムのシステム設計を学ぶことは、より良いエンジニアになることに資するでしょう。
システム設計はとても広範なトピックを含みます。システム設計原理については インターネット上には膨大な量の文献が散らばっています。
このリポジトリは大規模システム構築に必要な知識を学ぶことができる 文献リストを体系的にまとめたもの です。
通信や電力などをはじめとした重要情報を扱うシステムには、サービスの安定供給が強く求められ、非平常時でも自らの統制力を確保する「自律性」が要求されます。一方で、ビジネス環境や技術環境がめまぐるしく変化する今日では、変化への対応力など「利便性」を備えたクラウドサービスなどへの要求も高まっています。そこでIPAは、重要情報を扱うシステムの構築・調達・運用時に、管理者が「自律性」と「利便性」の双方を両立したシステムの要求仕様を策定できるようガイドを定めました。
本ガイドは管理者が環境の変化を捉え、それに伴う問題・リスクや利便性の要素を整理し、対策を検討しながら要求項目を取捨選択できるよう、次の3ステップ（下図参照）でシステムの要求策定を支援します。
1．システムの特性評価
まず、システムの特性を9つの項目で評価し、優先すべき「享受したい内容」を見極めます。9つの項目は「自律性」確保と「利便性」確保の2つに大別され、自律性の観点では「データの漏洩・改ざんなどの防止」を優先すべきか、「データの利用不可・システム停止などの防止」を優先すべきか、または両方なのかを見極めます。利便性の観点では変化し続ける「ビジネス環境への対応」と「技術環境への対応」のどちらを優先すべきか、または両方なのかを見極めます。
2．問題・リスク／利便性要素の選定
次に、1で整理した「享受したい内容」をもとに、自律性の観点では「問題・リスク」を、利便性の観点では「利便性の要素」を、樹形図を使って明確にしていきます。
樹形図を俯瞰することで、どの問題・リスクに対策を講じるべきか、どの利便性の要素をどの対策で得るべきかを検討しやすくなります。
3．必要な対策の選定
最後に、明確化された「問題・リスク」「利便性の要素」に紐づく「対策」を樹形図で選定します。
「対策」ごとの目的と詳細内容（要求項目）を表で一覧として示し、目的を理解しながら要求項目を選定できるようにしています。
読みづらいメカニズム
1. そもそもの処理の認識が誤っている
2. 変数名やメソッド名が英語で正しく表現できていない
3. 正しく表現していくと長くなる
- Cloudflareでは、大量のデータを処理するためにKafkaクラスタを採用しており、チームの分離、効果的なスケール、数兆件のメッセージの処理のために開発された汎用メッセージバスクラスタがある。
- イベント駆動型システムの非構造化通信の問題に対処するためには、強力なコントラクトを定める必要がある。そのため、CloudflareはクロスプラットフォームのデータフォーマットProtobufを用いている。
- 開発ツールのメトリクスへの投資は、問題を容易に明らかにするために重要である。CloudflareはSDKをOpenTracingとPrometheusのメトリクスで充実させ、システムの挙動を理解し、特にインシデント時により良い意思決定を行うようにした。
- SDKの採用や使用に一貫性を持たせ、ベストプラクティスを推進するためには、パターンに関する明確なドキュメントを優先させることが重要である。
- Cloudflareは、柔軟性とシンプルさのバランスを取ることを目指している。設定範囲の広いセットアップは柔軟性が高い一方で、シンプルなセットアップは異なるパイプライン間での標準化を可能にする。
カスタマイズに向きあうための考え方
- 全て除去しよう、負債を返済しようと思わないこと
- 上記Salesforceの話しかり、影響度的に摘出不可能なものもある
- 抱えてしまった負債は仕方ないと考えて、むしろこれと一生付き合う覚悟を持つ
- ただしカスタマイズを全て一覧化して把握する努力はする
- カスタマイズはバグの温床なので、それを踏まえてテスト設計をする
テキストコミュニケーションはある特殊な世代の流行に過ぎなかったのではないか。
だって今動画とか音声ファイル送れるじゃん。LINEの通話もあるし。
喋ったほうが早いし楽なのにわざわざテキストで重いコミュニケーションをするわけがない。さいきんの大学生がタッチタイプできないのも当然である。
2000年代からインターネットをしている私の世代は、その当時のインターネット技術の制約によってテキストコミュニケーションに特化しただけなのだ。これは今のインターネット環境とそぐわない。
これは一理ある
- はじめに
- 大前提として
- テストコードとセットでコードを書く
- コミットの粒度に気を付ける（blameしやすいコミット粒度にする）
- コミット粒度に関する参考文献
- 開発チケットへのURLをコミットメッセージに残す
- （必要であれば）コードにコメントを書く
- 解説ドキュメントを書いてそのリンクを載せる
- コード説明会を開いてその動画のリンクを載せる
- 書き手の意図が伝わるきれいなコードを書く（reprise）
- Q. コードの美しさなんて主観に過ぎないので意味がないのでは？
- 番外編：なるべく退職者を出さない
- 番外編その2：不要なコードやデータベースのテーブルやカラムは消す
- まとめ
- 自分の創意工夫をみんなで共有し合おう
研修がはじまるという画像でサーブレットJSPの本が並んでて、サーブレットを最初に勉強させるのをやめてあげてほしいと思った話。
オブジェクト指向もそうなんだけど、現状で使わなくなっているにもかかわらず情報更新がされずオブジェクト指向やサーブレットJSPが教えられ続け本が売り続けられるという現状がある。
でももうさすがに変わってほしさ。
ただ、JSPはそこまで悪くないので、サーブレットで話を進める。(ただし、サーブレットが動かない環境ではJSPは動かない)
最初に勉強するべきは「Webアプリケーションとはどういうものか」のはず。 そうすると、サーブレットの場合はサーブレット固有の仕様を知ることやTomcatのお守りをすることに時間をとられすぎて効率が悪い。
とくに講習の場合は時間が限られていて、そして15人から20人くらいいると、だれかが変なところではまって止まるということも少なくない。
「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」
って自分のチームのディレクターにお願いしたり
「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」
ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。
そういう情報をデイリースクラムで共有できるのはできる。でも、それは意図的に伝えて意図的に受け止めないといけないし、その情報のオーナーはエンジニアになってしまう。
そうすると、どうなるか。細かいことは全部、エンジニアに聞かないと分からなくなってしまう。「この部分ってどうなってますか？」「あー、エンジニアに確認しますね」という話がたくさんでてきたり「あれ？いまエンジニアどうしでそんな話になってるんですか？認識してませんでした」みたいな認識のズレがあとになってでてきたりする。
チーム内ならまだしも、チームを超えてこれが発生すると、関係者全員がストレスのたまる状態になってしまう。
そういうのを避けたいので、情報の流れを遠回りさせてる。スケジュールや組織間連携の話はディレクターが情報のオーナーになって共有して、プロダクトの仕様に関わる部分はプロダクトマネージャがオーナーになって決めていくような流れにしている。そんな細かいところはエンジニアでいいように決めたらいいやん？ってとこもプロダクトマネージャを通るように。そして、エンジニアはアーキテクチャやシステムの設計にオーナーシップを持つ。
TL;DR
- 「あえてやらなかったこと」をコメントしないと、レビュワーからは「知らなくてやった」と認識される
- 「あえてやらなかったこと」は、ほとんどの場合、ちゃんとコメントしておかないと理解してもらえない
- 「あえてやらなかった」ことを記載すると、レビュワーのコードリーディングの負担が減る
何が問題か
- 「あえてやらなかったこと」 = why notは、言語化しない限りは「知らなくてやらなかったこと」として認識される。
- レビュワーは「あえてやらなかったこと」だとわかっていれば指摘しなくても済んだ内容を指摘せざるを得なかったこと
- 後でコードを読んだ人も、そのコードにならってコピペでコード実装する可能性があり、パフォーマンス低下の温床になる可能性があること
どうしたらいいか
- コードコメントには、「あえてやらなかったこと」 = why notを書こう
ぼくはこの中で、タイトルにもした「Why not」の説明がいちばん好き。Why not ってだいたい[コードレビュー]でコメントが入りがちで「素直に設計したら◯◯になると思うんですけど、なぜそうしなかったのですか？」と聞きたくなるところに気の利いた Why not が置いてあると、やりとりが一往復へって最高に捗る感じがするからです。
この「[一往復を節約する]」ってのは共同作業全般においてぼくが重視したいことなんだろうなあ。これの積み重ねでタスク完了までに要する時間が大きく変わってくる、という感覚がある。
【Q】
スタートアップの代表です。
その職種の界隈では有名な人（特定を塞ぐため職種は伏せます）を採用したのですが、想像以上にパフォーマンスが低く、近く辞めてもらう予定です。
その方はフォロワーも多く実績も側から見たら凄いのですが、弊社では戦力になりませんでした。
今後私と同じような状況に陥る人は減らしたいと思いつつ、個人名だしてこの人はダメでしたというのは流石に気が引けます。
どのようにして、こういった被害を減らせるでしょうか？
-----
⚠質問したい人はプロフ欄のマシュマロから！
-----
【A】
なかなか難しいんですが、これ、「有名な人」というのは、結構フィットしないことがあるんですよね。
その人が無能なわけでもなんでもなくて、有名な人、フォロワーが多い人って尖り方が歪だったりするので会社によってはまったくパフォーマンスでないというのはよくあります。
おそらく、僕とかも、大体の会社で戦力にならない気がするんですよね。リクルートとかだと許容してもらえるとか、そういうのはありましたが、たとえば「Twitterをあまりやらないで」とか「勝手な動きや思いつきでやらないで」といわれるだけで、全然なにもできなくなります。
というなのでやめてもらうのはいいと思うんですが、わざわざ悪評を広げる必要はないかなと。「他の企業の被害を防ぎたくて」は余計なお世話なのでやらなくていいです。リファレンスがきても、「あくまでうちの会社だとこういう理由でフィットしなかった」という程度に抑えておいたほうがいいかなーと。
というのも、他の企業で圧倒的な成果をその人が出したら「あの優秀な人の悪評を流してた、あの会社の代表こそが無能だし、性格悪くない？」という風になるのは目に見えているので、そんなリスクをとらないほうがいいと思うんですよね。。
グウの音も出ない正論で草
聞かれてもいないのに他人の悪評広めたがるのはどう言い繕っても陰口でしかないので、「私怨でネチャネチャやんけ」「こいつ見えないところで俺の悪口も言ってんだろうな」と思われて、自らの評価を下げるだけなのだ。
マイクロソフトは開発環境をクラウドPCとして丸ごと仮想環境で用意し、デスクトップ仮想化経由で利用できる「Dev Box」の正式リリースを発表しました。
最近のアプリケーションの開発環境は、コードエディタおよび文法チェックやフォーマッタなどの拡張機能、ソースコード管理ツールとの連携、ビルドツールや自動テスト環境などをはじめとするさまざまなツールによって構成されています。
そしてこれらのツールチェーンを適切に稼働するように設定するだけでもある程度の専門的な知識が必要で、手間のかかる作業になっています。
Dev Boxはこうした開発環境やツールチェーンを、あらかじめ整備された仮想マシンとして用意することで、開発者はすぐに適切な開発環境を立ち上げて開発にフォーカスすることを実現するものです。
Dev Boxの仮想マシンはWindows 365上で構築されるクラウドPCと同じ仕組みを用いてデスクトップ仮想化の仮想マシンが用意されるため、ユーザーとなる開発者はデスクトップ仮想化のクライアントツールやWebブラウザ経由でリモートデスクトップとして利用できます。
仮想マシンという扱いになるのか
LiteFSは、SQLiteのデータベースをレプリケーションし、複数のSQLiteに対してデータベースの同期を実現するソフトウェアです。
マスターとなるSQLiteが何らかの障害で落ちた場合には、自動的に別のSQLiteへとマスターが移行する、フェイルオーバーの機能も備えています。
具体的な仕組みは、SQLiteのデータベースファイルとファイルシステムの間にプロキシをはさみ、トランザクション処理を検知して記録する独自の「Lite Transaction File」（LTXファイル）を作成します。
これを別のSQLiteへ転送し、そこで処理の内容を復元することでレプリカデータベースを実現します。
分散ファイルシステムとしてFUSE（File System in User Space）を用いることでLTXファイルを別のSQLiteへ転送し、HashiCorpのConsulによってサービスディスカバリや障害発生時のフェイルオーバーなどを処理しています。
これってマスターDBにWriteするAPIとエッジにレプリカDB（SQLite）を配信する仕組みだけで簡単に模倣できそうなんだけど、ビジネスとして成立するんだろうか？
/var/lib/docker/containers/<コンテナID>/<コンテナID>-json.log に保存されるNECは、わずか130億パラメータで世界トップクラスの日本語性能を有するという大規模言語モデル(LLM)を開発したと発表した。標準的なGPU 1枚を装備したサーバー動作可能と謳っている。
ChatGPTにより生成AIの1つであるLLMは注目を集めつつあるが、既存のLLMのほとんどは英語を中心に学習されているため、高い日本語性能を有しつつ、各業種の業務で活用できるカスタマイズ対応のLLMはほぼない状況だった。今回NECは、LLM性能はパラメータサイズだけでなく、学習に使われた高品質なデータの量や学習時間にも左右されることに着目。多量のデータと膨大な計算時間をかけることで高い性能を実現した。
ほかのLLMでは多数のGPUを必要とするのに対し、NECのLLMはパラメータ数を130億に抑えており、GPUを1枚搭載した標準的なサーバーで動作可能としており、業務アプリケーションがレスポンスよく動作し、消費電力やサーバーのコストを抑えられる。さらに、短期間で容易に構築可能で、オンプレミス環境でも動作できるため秘匿性の高い業務でも安心としている。
やっぱりモデルは契約しないと使わせてくれないか。
2022年には、動画編集アプリの「Splice」や画像補正アプリの「Remini」などを手がけるヨーロッパの大手IT企業「Bending Spoons」がEvernoteを買収することを発表していました。その際、Bending Spoonsのルカ・フェラーリCEOは「Evernoteをさらに進化させられるよう、今後も精進を重ねてまいります」と述べ、Evernoteのサービスが継続されることを明らかにしていました。
一方で2023年2月にBending SpoonsはEvernoteの従業員129名を解雇したことが報じられています。海外メディアのTechCrunchに対してEvernoteの広報担当者は、「同社は何年もの間経営状況が芳しくなく、このままでは長期的な経営は不可能でした。そのため、従業員の解雇は避けられない決断でした」と述べています。
相次ぐ従業員の解雇や値上げが行われる中で、2023年7月6日、Hacker Newsに「Evernoteの残りの従業員のほぼ全員が解雇されました」とのスレッドが立てられました。スレッドを立てたbaron816というユーザーは「Evernoteの事業を引き継いだBending Spoonsは、サービスの料金を引き上げ、得た収益は新機能の拡大に使用する予定であることをユーザーに伝えていますが、従業員がいない状況でその予定をどのように遂行するのかは、私が知りたいくらいです」と述べています。また「まだEvernoteを使用している場合は、使用をやめるいいタイミングです」と忠告しています。
なんでお前らチケットに書いてあることをまともに読まないの？文盲なの？
なんで流し見しただけで読んだつもりになって、ばかみたいな質問してくるの？
なんでほぼ毎回「それチケットに書いてありますよ」って言われてるのに、質問を送信する前に自分でdescriptionに目を通さないの？
人に質問する前にもう一回自分で読み直せよ、それが一番早いだろ。
送信ボタン押す前に再確認すればいいじゃん？なんでやんないの？ばかなの？
１００歩譲って、１０００歩譲って、１００００歩譲って、無駄な確認質問してくるのはまだいい。
ドキュメントに書かれてることを読まずに、ばかみたいな質問すらしてこないで、実装漏れすんのやめてくれよ。勝手な思い込みでヘンテコな実装すんのやめてくれよ。
なんかもう前提が欠けてるからむちゃくちゃ過ぎてレビューと修正にめちゃくちゃ時間かかってるじゃねえかよ。
ほぼ毎回レビューの結果もう最初に出てきたものと別物、別機能になってたりするじゃねえか。
「レビューを受けて修正しました」じゃねえよ、もう異世界転生だよ。
んで、リリース後に不具合や漏れが発覚した時に「不具合、実装漏れはどうしても発生してしまうからしょうがない」とか言ってんじゃねえよ。
どの口が言ってんだよ。ベスト尽くしてねえやつがそれっぽいこと言ってんじゃねえよ。
ただの人災だよ。お前のせいだよ。
ミスは誰でもすることだよ。でもそれを「ミスはしょうがない」だけで片付けてたら何も変わらないだろ。
ミスの原因を明らかにする。しかしそれを咎めない。そして改善を図るのがあるべき姿だろ。
でもミスの原因を明らかにしようとすると無駄にプライドの高いお前らが発狂して暴れるからチームの振り返りも地獄だよ。
お前らがドキュメントをまともに読まないことが根本的な原因なのに、長年そこを避けた斜め上の話し合いしかできなくてゴミみたいなMTGになってる。
4keysとか言ってんじゃねえよ、お前らはとにかく文章をまともに読む癖をつけろよ。話はそれからだ。
うちの開発チームの自己愛モンスターたちと、長年に渡って過剰に遠慮して本質的な議論ができない体制をつくってメンバーを増長させたクソCTOにこの文章を捧ぐ。
レコード移行する方法として以下の二つを検討しました。
- Rakeタスクで旧テーブルから新テーブルにレコードをコピーする。
- AWS BatchでS3の画像ファイルをコピーし、MySQLで直接レコードをコピーする。
その結果、以下の理由からRakeタスクを採用することを決めました。
- CarrierWaveを使用することで、レコードコピーと同時に新たなサムネイル画像を準備できる。
- Railsの機能を活用してレコードを作成するため、モデルバリデーションを適用できる。
- レコードのコピー速度が遅い場合でも、並行処理によってそれをカバーすることが可能。
- 検証環境での動作確認が容易。
大まかな流れと解説です。
- (1) Rakeタスクで引数によりIDを指定し、その範囲の旧テーブルのレコードを取得します。
- 引数でコピー対象の範囲を指定することで、タスクを並列稼働させることが可能になります。
- 範囲を指定することでRakeタスクの稼働時間を短縮し、万が一AWSなどで障害が発生した場合でも影響範囲を特定しやすくなります。
- (2) 旧テーブルのレコード情報をコピーし、その情報を使用して新テーブルのレコードを作成します。
- CarrierWaveにより画像ファイルがS3にアップロードされます
- この時点で新しいサムネイル用の画像も同時に生成されます。
- (3) コピーが完了した旧テーブルのレコードに新テーブルのレコードIDを保存します。
- 事前に旧テーブルに新しいIDを保存するカラムを追加しておきます。
- 旧テーブルのレコードを取得する際にコピー済みのレコードを除外することができます。
- コピー前後のレコードが紐づくため、正しくコピーされたかを検証できます。
[...]この2つのアクションによってRed Hatは、これまで当然のようにエンタープライズLinux市場に存在してきたRHELクローンOSベンダを全面的に否定したのです。そのインパクトは大きいといえるでしょう。
結局のところ、Red HatによるRHELクローンOSベンダに対する明確な排除の姿勢とアクションが明らかになった後も、クローンOSベンダ側のクローンOSの提供を継続する意志と能力に、少なくとも短期的に大きな影響を与えることはなさそうな状況です。
果たしてRed Hatはさらなる強い意志を持って、RHELクローンOSの存在に対してより強力な何らかの制限を加えてくるのか、あるいは静観へと移行するのか。これが今後の注目点になるでしょう。
15世紀に生まれた活版印刷を、オスマン帝国はほぼ即座に禁止した。結果、オスマン帝国の成人男性の識字率は19世紀になっても数%で、産業革命では欧州に大きく遅れた。似たような話は歴史上たくさんある。
これが「道徳的に問題があってもAIを使うのか？」という質問への、俺なりの答えかもしれない。
西欧や北米で鉄道が爆発的に発展していた19世紀半ば、東欧やロシアの支配者層は鉄道敷設に及び腰だった。兵力を素早く移動できるという利点は認識していた一方で、人々の自由な移動により農奴制が崩壊することを恐れていた。
結果、ロシアは経済発展で出遅れ、20世紀初頭には共産主義革命を経験する。
ここには、いわゆる〝トロッコ問題〟が存在する。「法的」には許されているとはいえ、AIの学習する画像データの出どころに「道義的」な問題がまったくないと言ったら嘘になる。違法アップロードサイトからも集めた画像で訓練されたAIを使うのは（AIヘビーユーザーの私でも）気持ちのいいものではない。
エドワード・ジェンナーは、使用人の息子に牛痘と天然痘を接種するという人体実験を行った。現代の基準でいえば、今あるすべてのワクチンは非道徳的な研究の子孫だといえる。それでも、ジェンナーの非道徳性を理由にワクチンを否定する人は滅多にいない。トロッコ問題を計算した結果、益が勝るからだ。
もちろん、ジェンナーの人体実験の被験者は遠い過去の少年一人なのに対し、AIに学習データを利用されてしまうのは現代のすべての絵描きだ。これをまったく同じだと論じるのは無理がある。とはいえ、〝トロッコ問題〟として捉えると、その構造には類似点がある。と言えなくもない。
今の科学技術では、どう逆立ちしても交通事故はゼロにはならない。ではなぜ、自動車は禁止されないのだろう。自動車メーカーは（もちろん望んでいるわけではないが）自分たちの製品でアホをやらかすやつがいることを分かった上で、それを販売している。私たちの社会は、なぜそれを許容できるのだろう。
ある技術の倫理的善悪と、私たち一人ひとりの感情的な好き嫌いと、社会にもたらす損益とは、それぞれ別レイヤーの問題だ。さらに実現可能性の問題もある。「禁止すべき／普及すべき」という結論が出せたとして、その結論に実現可能性がないのであれば、それは机上の空論にしかならない。悲しいけれど。
画像生成AIを「単なる贋作製造マシン」だと捉えている人には、私の言葉は届かないかもしれない。私は経済史が大好きな人間なので、モノを考えるときにそれを参照してしまう。（画像生成に限らず）AIは、活版印刷や蒸気機関、鉄道、写真、映画、電子計算機に匹敵する発明だと、私は捉えている。
鉄道以前の世界では、馬よりも速く地上を移動できる手段はなかった。日本標準時のような統一された時刻は存在せず、町や村によってバラバラだった。兵士を前線に送るまでに何日もかかり、野菜や魚やビールは生産地の近隣でしか消費できなかった。しかし鉄道は、すべてを変えた。
高精度の腕時計を身に着けて、分単位でスケジュールを組んで働くという現代人の姿を、鉄道以前の世界の人々は想像できなかったはずだ。駅馬車はときには数日単位で遅れることもあった。分単位の予定を立てることなど不可能だったし、立てる意味もなかった。
画像生成AIの登場は、ほんの序章に過ぎない。この先の半世紀で、私たちは鉄道の登場と同じかそれ以上の極端な変革を味わうことになるはずだ。Midjourneyがバズった7月末、私たちは2ヵ月後の今の状況すら予想できなかった。これが10年後には一体どうなっているだろう？
鉄道が登場した頃の農夫がAppleウォッチを想像できなかったように、今の私たちには未来が分からない。ただ「予想できないほど世界が変わってしまう」ということだけは分かる。画像生成AIは（そういう使い方もできるけど）ただの贋作製造マシンではない。鉄道のような「何かの始まり」だと、私は思う。
〝トロッコ問題〟を解いた結果、私は画像生成AIを使っている。「悪い結果」と「もっと悪い結果」とを比較して、マシなほうを選ぶという功利主義に従っている。たとえ法的に問題なくとも、今までの私たちの慣習からいって、画像生成AIには道義的な気持ち悪さを覚える。それでも、もはや無視はできない。
もはや無視できないからこそ、できるだけ多くの絵描きさんに画像生成AIを使って欲しいとも思っている。プロアマは問わない。画像を学習されるだけの被害者〝のような〟立場に甘んじるのではなく、AIを味方につけて乗りこなす騎士になって欲しい。AIしか使えない画力ゼロの雑魚をなぎ倒して欲しい。
コンテナ・仮想マシンの管理システムである「LXD」は、lxcコマンドを駆使してCLIで管理します。長らくLXD向けのGUIが求められていましたが、先日ようやくWeb UIが実験的に投入されました。今回はこの「LXD-UI」を実際に試してみましょう。
2023年7月5日、名古屋港統一ターミナルシステム（NUTS / Nagoya United Terminal System）でシステム障害が発生しており、システムを管理する名古屋港湾協会は障害原因がランサムウエアによるものと公表しました。ここでは関連する情報をまとめます。
機能の話なのか、規模の話なのかという問題。
機能自体は大したことないけど、それを全世界の数億ユーザーに提供するインフラ設計が想像の外というイメージ。
GoFのデザインパターン、あと実装継承は現在のオブジェクト指向プログラミングで実際に使う機会は多くはない。
フレームワークやライブラリーのコードリーディングのためには必要な知識だが、アプリケーションプログラミングではどちらも知っている価値はあまりないかも。
画面中心に要求を決め、通信仕様もデータベース設計も画面要求に従属させる。
プログラムの構造は画面から受け取ったデータの処理単位に分ける。
すべてのロジックを画面処理の一連の手続きの中に埋め込む。
これで不具合が起きにくく、起きても修正が簡単で、機能追加が楽で安全ならばよいわけだが…
GoFのデザインパターンで有用なの、ストラテジーパターンぐらいしかない疑惑が拭えない（アプリケーションプログラムの文脈で）
Data Engineering Study #20「10年戦えるデータ分析入門」回・前半の発表資料です。
SPACEは達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency)の頭文字を取ったものだ。これらのディメンションはいずれも、生産性を理解し、計測する上で重要な鍵となる、と研究者らは言う。その上で、それぞれのディメンションに対して、個人、チームあるいはグループ、システムレベルなど、さまざまなレベルで適用されるメトリクスを数多く提案している。興味深いのは、すべてのメトリクスを同時に使用することは推奨せず、逆に、これら3つのレベルすべてにわたって、さまざまな生産性のディメンションを捕捉するメトリクスセットを小さく保つように、注意深く選択することを勧めている点だ。
7月1日23時頃よりSNS『Twitter』が「API呼び出しの回数制限を超えました」と表示され、閲覧できない状態になる人が続出して騒ぎとなっていますが不具合ではなく（一時的な）仕様だと発表がありました。
7月2日2時1分、イーロン・マスク氏は自身のTwitterアカウントで「極端なレベルのデータスクレイピングやシステム操作に対処するため、以下の一時的な制限を適用しています」と発表しました。
それによると制限は
- Twitter Blue（課金）ユーザー：1日6,000件まで閲覧可能
- 無料（無課金）ユーザー：1日600件まで閲覧可能
- 新規（未認証）ユーザー：1日300件まで閲覧可能
になっているとのことです。
6時49分、イーロン・マスク氏からそれぞれ10,000件、1,000件、500件まで制限を緩和したとの発表がありました。
まぁ、APIをあんな風にしてしまえばスクレイピングに走る奴は多かろうという話だ。
インターネット上にログを残す用途にTwitterが使えなくなった今、代替手段として何があるだろう。昔に立ち戻るのであれば、ミニでない普通のブログに記録し、RSSリーダなどのアグリゲータで更新情報を得る、という方法になる。
ただもうSNSにどっぷりと浸かってしまった私にはこの方法は面倒くさすぎる。ちょっとした情報をいちいちブログに起こすのも面倒、RSSのリストを整備するのも面倒、リンク先のブログにいちいち飛ぶのも面倒、ブログにコメントを残すのはハードルが高い、リツイートはできない。
ログとアグリゲートを同時に扱うことで得られるSNSの利便性を、分散型のログと個人ごとのアグリゲータで実現するのは色々と難しそうだ。ただSNSがクローズドになっていっている今、オープンなSNS代替として、SNSと同等の使い勝手を目指したブログ＋アグリゲータが出てきたりしたら面白いのだが。
Twitterがサービス終了しても次のTwitterがすぐ生えてくるんだろうけども。
富士通は29日、マイナンバーカードを使ってコンビニで証明書を交付するシステムを再び止めて点検すると発表した。同社の子会社が証明書交付システムを運営しているが、システムを利用する全自治体が再点検の対象となる。
3月から複数の自治体で別人の証明書が誤って交付される不具合が相次ぎ、5月から約1カ月かけてシステムを点検した。6月17日に点検が完了したが、新たに福岡県宗像市で住民票の誤交付が発生した。
各自治体と調整してシステムを止め再点検を始める方針だが、再開時期は未定。
3月以降、横浜市や東京都足立区などで証明書の誤交付が相次ぎ発覚し、プログラムを修正してきた。デジタル庁の要請を受けて、5月下旬からシステムを一時停止し、総点検した。点検は完了し異常がないと6月20日に発表した。
26日に横浜市で開いた定時株主総会では、時田隆仁社長が誤交付問題について「国民のマイナンバーに対する不信の発端となった。深くおわび申し上げる」と陳謝し、再発防止に努める考えを示したばかりだった。
これもうコードが改修・テスト不能になってるか、「とにかく○○日までに再リリースしろ」みたいなマネジメントのゴリ押しで開発体制が崩壊してるかしてそう。
あるいは、SESで頭数を揃えて雑に開発→リリースしたから人間もリリース→細かい仕様を知ってる人間がいねぇ状態とか。
うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。
バグが直った時に、slack上では開発チームに「修正ありがとうございます」って送ってるけど、なんで自分たちが「ありがとうございます」と言っているのかよくわからない。
開発チームが品質の悪いシステムをつくって、
お客さんがバグを見つけて怒って、
カスタマーサポートがお客さんのサンドバッグになって、
開発チームがバグを直して、
カスタマーサポートが開発チームにお礼を言う。
なにかがおかしい。なんだこれ。
自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。
カスタマーサポートはお客さんをサポートするための仕事なんだよ。
不出来な開発チームのための緩衝材じゃないんだよ。
本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。
でもできないんだよ。
毎週炎上して、毎日謝ってるんだもん。
新機能が出てもまともに動くとは思えないんだもん。
新機能出るじゃん？
お客さんに使ってもらうじゃん？
動かないじゃん？
怒られるじゃん？
どうせこうなる確率が１００％なんだから、それだったらもう新機能が出てもお客さんに伝えないほうが得じゃん？
もう新機能とか開発しなくていいから、ひたすらちょっとしたメンテナンスだけしててほしい。
余計なことしないでほしいというのがサポートチームの総意です。
なんでこの人たち給料が高いんだろう。
Pythonの三項演算子の書き方がネイティブ的には自然という学びがあった
「10年間互換性を保ったままセキュリティパッチが提供され続けるOS」を維持するのが年々しんどくなってるのは想像に難くなくて、タダ乗り行為を見過ごせない段階まで来たのだろうとは思うけど、コミュニティが納得しそうにない所に踏み込んだのは賭けだなと思いますね。
そもそも10年も入れ替えなくて良いOSなんてものにユーザーを甘えさせておくのが果たして良いことかどうかってのは別の問題としてありますね。オープンソースを利用する上で本来かけなきゃいけないコストの存在を知らないままシステムを運用し続けてしまってる会社いっぱいあると思うよ。
OSSのIssueのテンプレートと、私のSlackの定型文に共通しているのは「知識ある開発者の手元に自分と同じ環境を、できる限り開発者の時間を使わずに再現すること」だと思います。
[...]
そこで、1秒でも短く、一手でも少なくエラーを再現できるようにエラーを報告する側が時間を使うべきだと私は思います。仮に自分が15分かけて再現手順を用意した結果、知識ある人が3分で修正できたなら、それはものすごく価値ある時間の使い方でしょう。
例えば、ミーティングを設定する前に「新機能の仕様について相談してもいいですか？」と許可を求めるのではなくて、先にミーティングを設定して「16時から新機能の仕様の相談をするミーティングを入れたのでお願いします」というようにお願いをすると、コミュニケーションの回数を一回減らせます。
これは、時間を効率的に使うための工夫です。リモート開発ということは、相手がすぐに返事ができる状態ではないことが多いです。返事を待っている間に16時になってしまうかもしれません。
[...]
これを応用すると、仕様の相談をするときに、「A案・B案どっちがいいですかね？」ではなくて、「A案・B案あるんですが、こういう理由でA案で進めさせてください」とお願いできます。相手は「A案でOKです」か「A案だとこういう時どうなりますか？」や「それはダメなんです」とすぐに議論が始められます。
こういう小ネタ的なコミュニケーションTipsを集約して、開発現場で使えるコミュニケーション・プロトコルとして一般化できないか考えることがある。
例えば、救急救命の現場で即断が必要な場合は調べる暇がないから頭にある知識で対応せざるを得ない→だから暗記は重要だというロジック。
とはいえ、現実的な応答速度で選択肢をピックアップしてくれるシステムがあれば、それを使いたい（可能なら失敗時の責任も押し付けたい）医者は多いと思うし、理想的にはそうなるべきだろう。
なので、やはり暗記は現状のUIやシステムの問題でしかなく、将来的には暗記が重要になる分野は極力減らしていくべきではなかろうか。
口伝であらゆる情報を伝えていた祭司や司教が自分の役割が脅かされる事を恐れて文字や印刷物を嫌悪した故事に似たものを感じる。
本質的な問題(問題ではないかもしれない)は現代では OSS とそのドキュメントの品質が劇的に向上し、人類一般の技術力も爆発的に伸びたので、サポート買わなくてもみんなソフトウェアを運用できるようになってきたというのがあって、結局もう Red Hat 地球に存在しなくてもよくなりつつあるんだよな。
誰かが金を払わないとソフトウェアは出来ないので、たぶんどこかで何かビジネスは回り続けるんだろうけど、 OSS をビジネスの中心に据えるのはもうだいぶ無理があるんじゃないかな〜
うーむ
会社「炎上案件のヘルプを頼む」
社員「わかりやした」
〜査定〜
社員「鎮火させたしA評価やろ」
会社「単価増も増員もできてないしC評価」
社員「は？辞めるわ」
これたまに見かける。
デジタル庁は6月27日、Webサイトやアプリケーションの開発で利用できるイラスト素材の配布を始めた。12日の予告通り、無料で提供する。商用利用も可能。
パスポートやマイナンバーカードを示すイラスト、税金を表すアイコンなど、計400点以上の素材を配布。出典やクレジットの表記なしで利用できる。ただし改変・編集の上利用したり、再配布したりする場合は、出典と共に加工内容を明示する必要がある。
「地方自治体、府省庁、民間企業が誰でも利用できる素材を配布することで、別々の機関が同じものを制作したり、検討する時間を省く」（デジタル庁）という。アイコンなどを共通化し、ユーザーが一目で理解しやすいデザインを広げることにもつなげる。今後は実際に利用する自治体や企業の声を踏まえ、順次素材数を増やす。
マイナンバーのイラストが公式提供されるのは助かる人結構いそう
JR東日本は6月26日、24日に発生した、モバイルSuicaでのチャージなどができなくなった障害について、電源工事のミスが原因だったと発表した。工事マニュアルに間違いがあり、計画と異なるブレーカーを切ってしまったことで、システムサーバへの電源供給が止まってしまったという。
原因は、屋内の電源工事。マニュアルには本来「盤NO6（CV6）内のブレーカーを『切』にする」と記載されるべきところ、「盤NO6（CV4）内のブレーカーを『切』にする」と書かれていた。
作業スタッフがこの誤りに気づかず、「盤NO4（CV4）」のブレーカーを切ったため、夜間処理中のシステムへの電源供給が止まり、ハード故障やデータ不整合が発生した。
障害発生から完全復旧まで約12時間かかった。サーバ電源を再投入し、ハードウェアの健全性を確認した後、電源供給停止時に実行されていた処理の再実行やデータの整合性を確認した上でサービスを再開したため。
再発防止のため、現地の電源盤の盤面に注意を明示。マニュアルの作成段階でのチェック体制も強化する。
あらまぁ...
64bitのCPUは、優れていないから。
唯今現在でも、電卓を作るのに「64bitのCPU」など不要です。100円ショップから電卓の注文が来た時に「64bitCPUの方が優れているのだから・・・」などと考える開発担当者はいません。質問の「優れている」の定義にコストも含まれるべきこと、当然でしょう。
世にワンチップCPUが存在しない時代に「４ビットの汎用CPUがあったら電卓のコストを下げることができるのではないか？」と着想した日本人がいて、「そりゃ面白そうだから作ってみよう」というインテルのエンジニアがいて、最初のCPUが生まれました。じきに「これは使える」と評判になってさまざまな分野で使われるようになり、「せっかくなら８ビットCPUがあれば、もっと便利・・・」となりました。こうして生まれた８ビットCPUは応用分野が爆発的に広がりました。そこで初めて、「これならコンピュータが作れるじゃないか」とコンピュータを作る人があちこちに現れました。アップルの最初のＰＣを作ったスティーブ・ウォズニアックさんもそんな人の一人です。ここでやっと、そのような新しい、小さなコンピュータに「パーソナルコンピュータ」という名前が付きました（日本ではマイクロコンピュータという名前が先に広まっていました）。
そうなると次は「パーソナル」とはいえコンピュータなのだから、８ビットよりもっと大きなビット数の演算器がほしい、ということになります。じゃぁ64ビット、にはならない理由は他の回答に詳しく説明されています。設計技術、製造技術の進展に歩調を合わせて、16ビット → 32ビット → 64ビットと進歩してきたのです。
64bitCPUがあっても4GB以上のメモリを載せると数十万〜100万円以上しますではPC市場では売れないから仕方がなかった。
逆にコストを掛けてもよい分野（軍事や気象予測、科学計算など）は割と早い時期に64bitマシン（スパコン）が投入されている。
最早この資料をアップデートし続けるだけで一生食っていけそう
Microsoft ResearchのAI研究チームは6月20日（現地時間）、わずか13億パラメーターと従来のものよりもサイズが小さいにも関わらず「GPT-3.5（1750億パラメーター）」を上回る成績を収めたTransformerベースの大規模言語モデル「phi-1」を発表した。このモデルは間もなく「Hugging Face」で公開される予定だといいう。
東京など1都3県のデータセンターの平均稼働率が9割に迫り、新規ユーザーの募集停止のリスクが出てきた。加えて足元では、電力費などの上昇による利用料値上げもユーザー企業を直撃しそうだ。デジタル変革（DX）を進めたい企業が、システム基盤の確保という出だしで足をすくわれかねない。
都内はともかく、神奈川・千葉・埼玉あたりはデータセンター豊富にあると思ったけど、それでも需要を満たせないのか。
Meta AIは16日、音声用ジェネレーティブAIモデル「Voicebox」を発表した。音声やテキストを入力して、音声合成やオーディオクリップの作成、ノイズ除去、コンテンツ編集、スタイル変換(Style Transfer)、多様な音声でのサンプル生成などに対応する。
Voiceboxでは、トレーニングデータを使わずに、収録した音声と補足する書き起こしから学習するアプローチを採用。Flow Matchingと呼ばれる手法により、音声合成において、最新の英語モデルVALL-Eを、明瞭度と音声類似度の両方で上回るほか、20倍高速化しているという。
名前や命名規則の統一とか書き方の統一とかは用語のリストを作って、命名規則を作って・・・など、コードフォーマッターとか、バリデーターを入れたら全自動だか半自動で解決する話題です。
クリーンアーキテクチャとかレイヤードアーキテクチャの話題もよくあがります。昔もデザインパターンが話題になったり、MVCが話題になったり、みんなお手本が欲しいんだな、という感じです。ただ、この手のものって、型にはめるためにある程度冗長であることを要求されるというか、コード量は増える傾向にあります。あと、オブジェクト指向はネジや釘として残っているが、ウェブフロントエンドはどのフレームワークもsignalやhooksによるリアクティブな設計に向かっていて、stale when revalidate戦略を活用したり、20年前のオブジェクト指向のアーキテクチャ議論はもう完全に過去のものだなぁという実感があります。
最後の残るものは、その時々によって意思決定の結果が変わる生ものです。結果が毎回変わるのであれば、あまり参考にならないかというとそういうことはなく、「どのようなトレードオフを考えて意思決定をしたのか」という思考の流れは参考になります。そのような意思決定こそがソフトウェア設計の醍醐味と言えます。
Clean Architecture + CQRS + モジュラーモノリスって感じだろうか
そもそもjsonデータをRDBに書き戻すことの是非は置いておいて、取り組む際に重要となる点としてjsonデータの更新があると考えております。ファイルとして扱うのであれば、jsonファイル全体を更新することでユーザは最新データを取得することができます。一方で、RDBで扱うにはjsonのデータ内部を検査し、差分更新を適切に行う必要があります。
JSON型などの利用についても考えましたが、参照はできるだけ普通のSQLでやりたいということもあり、あまり更新系の都合で参照系で変なことをしたくないということがありました。
そこで今回、こういったことを考えるためにJson2RDBというプログラムを作成しました。
やっていることは非常にシンプルです。jsonデータを列にバラして保存したリレーショナルデータベースに対し、更新内容をjson形式で与えることで差分を更新しています。
外部システムのデータをPULLしてきて蓄積するタイプのシステム大変だよね（小並感）
かと言ってPUSHしてもらうタイプの連携もそれはそれで大変だけど。
https://anond.hatelabo.jp/20230611160913
のつづき
■ Web3ヤー「ブロックチェーンのスマートコントラクトの仕組みを使えば、ガチャやゲームロジックを透明でフェアにつくれる！！」
解答「ガチャをはじめ、ゲーム性に不可欠な乱数を扱うのはブロックチェーンではそもそも困難です。乱数を得るのに、乱数オラクルと呼ばれる外部サービスに依存しなければならず、しかもそれが高価だからです。ゲームのような頻繁に乱数を要するようなユースケースには耐えられません。それを嫌って、乱数オラクルを自社運用したとすれば、ソシャゲのガチャと何も変わりません。むしろ金銭的利益と直結するBCGにおいては、運営側に乱数を操作するインセンティブが生まれるので、運営の不正が蔓延するでしょう。」
※別解「ゲームロジックのようなデータ量が多くて複雑な計算は、手数料が高すぎてスマートコントラクトでは実行できません。結局、重い処理は今まで通りブロックチェーンの外で行わなければいけないので、フェアなロジック実行、チート対策などが、ブロックチェーンだからできるということにはなりません。」
■ Web3ヤー「GameFiが来る！」
解答「ゲーム内資産を金融商品化するせいで、ゲームがギャンブルになってつまらなくなるのです。GameFiは本来のゲーム性を破壊する悪の根源です。出てってください。」
■ Web3ヤー「メタバースと組み合わせよう！」
解答「全く関係ありません。VR界隈から嫌われているので、はやく片思いだと気づきましょう。」
■ Web3ヤー「AIと組み合わせよう！」
解答「全く関係ありません。AI界隈から嫌われているので、はやく片思いだと気づきましょう。」
■ Web3ヤー「ブロックチェーンはRollupで無限にスケールする！！」
解答「Rollupによるスケールはシステミックリスクを増大させる恐れがあり、銀の弾丸とは呼べません。複雑なインセンティブ設計で維持されている流動性ブリッジで接続し合うRollupの網の目は、マネーレゴの一部品のハッキングやラグプル、ブラックスワンイベントをきっかけに、悪影響が波及して全体として崩壊しかねません。WEBがスケールしたのは、一部の障害が全体に無影響であるからです。トークンを触媒にして密結合するRollup網は、大きくなればなるほどシステミックリスクが高まり、むしろ脆くなっていくのは想像に難くありません。」
※別解「スケールすればするほど、Time-bandits攻撃と呼ばれる攻撃のリスクが高まるでしょう。子レイヤーで発生するMEVの合計が、親レイヤーのバリデータのペナルティを差し引いても十分に余るようになれば、親レイヤーの安定したコンセンサスを守るためのインセンティブ設計が成立しなくなります。」
■ Web3ヤー「ステーブルコインはWeb3のキラープロダクト！！」
解答「Web3といいながら政府発行の法定通貨に依存するのですか？恥を知りましょう。それはプロダクトキラーの間違いです。Web3がこのような新しい用語を頻繁に発明するのは、矛盾を巧妙に隠蔽するためです。ステーブルコインはそれに最も成功したバズワードの一つです。」
■ Web3ヤー「次はReFiが来る！！」
解答「善悪を恣意的に定義し、経済的インセンティブで善に誘導するのは新しい共産主義です。」
■ Web3ヤー「分散ストレージつくります！！」
解答「ブロックチェーンはデータの保管には向いていません。ビザンチン耐性だけなら分散DBで事足ります。もし改竄耐性が欲しいのであれば証明書チェーンのような仕組みで事足ります。すでに一部の界隈ではブロックチェーンではなく、VDR（Verifiable Data Registry）という言葉が代わりに使われるようになっています。ブロックチェーンはわざわざ使わなくて良いのです。」
■ Web3ヤー「ブロックチェーンを使ったビジネス！」
解答「ブロックチェーンが必要となるのは、悪玉ピアを含む不特定多数が参加するP2Pネットワーク上で、読み書きの権限を不特定多数に開放している台帳プロトコルの状態遷移のコンセンサスを取りたい場合のみです。ビジネスにおいてここまで過酷なことを要求される場面はほとんどありません。特に不特定多数を相手にするという性質がコンプライアンス遵守と相反するのでビジネスにならないことが殆どです。数年前からWhy Blockchain？という問いに挑んできた企業の多くがブロックチェーン事業に挫折したのはここに起因します。」
■ Web3ヤー「インターネットも黎明期はバカにされていた」
解答「インターネットは通信回線やパソコンの普及などインフラやハード面が未熟だったためその真価が発揮されるまで時間がかかりました。しかしWeb3で不便とされる側面は、物理的なものではなく原理的なものに起因します。ブロックチェーンのトリレンマから言えば、分散性を諦めない限りスループットは上がりませんし、手数料も安価にはなりません。悪名高いパスフレーズはなくせません。それらは性質として受け入れないとならないのです。また、詐欺が多いという非技術的な課題は規制でしか解決できませんが、Web3業界は規制を目の敵にしています。自ら課題解決を放棄しているのです。」
※別解「インターネットをバカにしてたのは外野だけじゃん。実際に触ってた人はみんな楽しんでたよ？Web3触ってる人で楽しんでいるのは稼いでる人だけじゃん。ゼロサムゲームおつ。ﾁｭｯ、ネット老人でゴ・メ・ン♫」
■ Web3ヤー「性欲がWEBの発展に寄与したなら、Web3は金銭欲だ。人間の欲求に応える分野は伸びる！」
解答「性欲は無限です。しかし資本は有限です。」
■ Web3ヤー「#Web3ならできる」
解答「できません」
■ Web3ヤー「日本は規制が厳しいからドバイに行ってやる！日本ってやっぱクソだわ。」
解答「日本だけでなく世界中のWeb3ヤーがドバイに集まっています。あなた方が、ドバイに追いやられているのです。」
日本政府「Web3を国家戦略に！」
解答「GAFAMに負けたことを悔しがるのは大切ですが、一発逆転を狙って一過性のバズワードに躍らされるのはやめましょう。まずは、日本がGAFAMに負けたのではなく、アメリカが世界で一人勝ちしていることに着目して戦術ではなく戦略を立ててください。」
※別解1「そのまえにマイナンバーをどうにかしてください」
※別解2「まずはこの一問一答に対する反論を考えてください。」
アメリカがクリプト規制に本気出し始めたので本邦Web3ヤーたちがざわざわしています。さらなる詐欺の撲滅のため、彼らが常用するレトリックとそれに対する正しい反応をあらかじめ書き連ねました。これらが有耶無耶のまま来年ビットコインが半減期を迎え、万が一雰囲気で相場が好転すると、耳さわりの良いポジトークが増えていくでしょう。これ以上被害者を出さないためにWeb3ヤーワクチンを打ってください。
■ Web3ヤー「ゲンスラーのせいで損した。SECは投資家を保護するんじゃないのか？」
解答「あなたが損した分、ショートしている人は儲かっています。あなたのポジションはSECも守ってくれません。そもそもトークン自体に価値があるなら、その価格がドル建てで上がろうか下がろうか関係無いはずです。それなのに価格の上下で一喜一憂するということは、そのトークン自体に価値がなく、ドルに価値があると自ら告白しているようなものです。そんなトークン遊びは規制されて当然でしょう。」
■ Web3ヤー「ゲンスラーは昔と言ってることが違う！Binanceに就職しようとして落とされた私怨でBinanceにやり返す姑息な奴だ！」
解答「むしろ考えるべきなのは、そんなゲンスラーでもこうなってしまうほどアメリカはクリプト規制に本気を出していることです。ゲンスラーすらSEC相手には犬なのです。個人攻撃で国がひっくり返るほど、アメリカは中央集権的な国家ではありません。もっと大きな敵を相手にしましょう。それを突き詰めていくと、規制がないことを良いことに、資金洗浄やテロ資金供与に目を瞑り、いい加減なポンジスキームを乱立させて、マネーゲームに狂乱したあなた方が本当の敵だったことを発見するでしょう。」
■ Web3ヤー「アメリカはイノベーションを保護しろ！」
解答「クリプトはイノベーションだったのでしょうか。イノベーションは誰かの役に立つからイノベーションなのです。金融ゲームに勝ってドルを誰かから奪える以外のユースケースを挙げてください。」
※別解「暗号資産はそもそも国家に依存しない通貨というコンセプトのもと発明されました。その暗号資産は、国家に保護されるべきものなのでしょうか。国家からの保護が必要なら、その挑戦に失敗した、ただそれだけではないでしょうか。」
■ Web3ヤー「こうなったのはすべてアメリカの陰謀」
解答「あなた方の間違いを認めたくがないために、無理やり陰謀論で帳尻合わせですか。本当に失望しました。試しにアメリカのTwitterトレンドを見てみましょう。誰もクリプトのことなんか話していませんし、見つかるのはbotterによる詐欺ミームコインのエアドロップの告知ツイートだけです。これを見るだけでもクリプトは百害あって一利なしだと分かるでしょう。あなた方のようなルサンチマンに陥ったイノベーターに誰がついていくのでしょうか。あ、イノベーターではないか。そーか、そーか。」
■ Web3ヤー「DeFiは政府や企業にコントロールされない金融システムです！」
ゲンスラー「規制しまーす」
■ Web3ヤー「俺らからイノベーションを奪うな！」
「ふぁっっ？」
■ Web3ヤー「DeFiは、途上国や様々な事情で金融サービスにアクセスできない人々のために、検閲されないオープンな金融システムを実現します！」
解答「DeFiは金融リテラシーが低い人には向きません。スキャムやポンジスキームのプロジェクトに溢れているからです。金融インフラが進んでいない地域では金融教育も行き届いていないことを想定すると、そのような地域の人々が安心して触れるものでは決してありません。途端に泣き崩れる嫁が大量発生するでしょう。」
※別解「え、DeFiって、金融強いマンたちが、余裕資金で脳汁ブシャーに興じるオンラインカジノじゃないんすか？途上国の人から見ればDeFiの手数料だけで一ヶ月暮らせるけど？」
■ Web3ヤー「クリプト業界のプロダクトは99%詐欺だけど俺たちのは違うぜ！！！」
解答「みんなそう言ってるから信じられません。そもそも、その断り文句を入れなければならないあなた方のその業界は、何かが根本的に間違っています。」
■ Web3ヤー「うちのDAOのガバナンストークンは、過半数はコミュニティに分配してます！」
解答「そのコミュニティに運営が成り済ますことが技術的に簡単にできる以上、我々投資家はあなた方を信頼しなければなりません。そんなあなた方が発行するトークンを証券と呼ばずに何と呼べばいいのでしょうか？」
■ Web3ヤー「エアドロップするから、うちのサービス使って！」
解答「プロダクトの素晴らしさではなくて、エアドロップで集客しなければいけないプロダクトのバリューは何ですか？エアドロップが自己目的化してませんか？」
■ Web3ヤー「エアドロップは未定です。」
解答「エアドロップで客引きするのがダサいと分かっているから、未定で誤魔化しているのでしょう。こう言うプロジェクトからはエアドロップしたい下心が透けて見えます。いずれVCに突かれてエアドロップするでしょう。」
■ Web3ヤー「エアドロップはしません」
解答「真面目なプロダクトはこの業界では報われません。触っても無駄なので無視しましょう。」
■ Web3ヤー「NFTをフリーミントします！」
解答「エアドロップができない日本のプロジェクトが取る日本特有のマーケ戦略です。基本ミントしても何にも起こりません。くだらない電子ゴミにしゃぶりついた黒歴史がブロックチェーン上で全世界に晒されるだけです。絶対にやめましょう。」
■ Web3ヤー「うちのプロトコルのソースコードは監査済みなので安全！」
解答「今までハッキングされたプロジェクトもそう言ってきました。それでも大丈夫と言える根拠を述べてください。」
※別解「そんな定型句は聞き飽きたので、あなたのチームに朝鮮訛りかロシア訛りの英語を喋って、リモート会議で顔見せない開発者がいないかだけまず教えていただけますか？」
■ Web3ヤー「最近はハッキングされても犯人からお金が返ってくる！」
解答「それは仮想通貨取引所が全世界的にAML/CFT対策を強化してきた努力の成果です。現在の暗号資産はハッキングしても大規模な資金洗浄が困難になっています。規制の恩恵に守られながら、Web3ウェーイ、政府なんていらねーぜウェーイ、とイキるのは恥ずかしいのでやめましょう。」
■ Web3ヤー「ハッカソン開催します！」
解答「ハッカソンはWeb3業社の主要事業です。自社エンジニアに去られ、プロダクトのネタが切れ、エアドロップもしてしまったWeb3業社はやる事がありません。何かやっているアピールのために、ハッカソンを頻繁に開催して事業を偽装しています。そんなハッカソン会場には、闇バイト戦士をリクルーティングしようと怪しい人がウヨウヨしています。気をつけましょう。」
■ Web3ヤー「イベント開催します！」
解答「イベントもハッカソンに次ぐ事業です。英語で何かを聞かされますが何も中身はありません。ポジショントークと馴れ合い、プロ驚き屋たちのサクラトークだけです。分かりやすい英語で話してくれるので、いいリスニングの練習になります。また、会場にいるWeb3女子の9割はバックに怖い人たちがいます。近づいてはいけません。」
■ Web3ヤー「〇〇ポジション採用中」
解答「組織内部が崩壊していますと同義です。Web3の中の人はとっくにヤバさに気づいて逃げています。特にエアドロップを終えたプロジェクトは新規で入る人には何の旨味もありません。また、トークンをもらえても、証券認定されれば、むしろトークンを持つことで面倒なことに巻き込まれる可能性があります。関わらずが正解です。」
■ Web3ヤー「イベント登壇しました。有名な〇〇さんとツーショット（ｶｼｬ」
解答「Web3起業家ワナビーが取りがちな行動です。しかし、そういった仲間意識から生まれる信頼関係の重み付きグラフから権威が創発され、権威が国家権力を生み出し、やがて私有財産権を脅かすに至ったアンチテーゼとして暗号資産は生み出されたはずです。ドバイやシンガポールの村社会は楽しいですか？仲間と内輪ノリで楽しくやっててください。政治家と写真撮って、偉い人と握手して、セルフブランディングして、素晴らしいプロダクトを世に送り出してください。待ってます。」
■ Web3ヤー「ブロックチェーンエンジニアです！」
解答「さぞ難しそうなことをしている響きですが、JavaScriptしか書けない弱々エンジニアです。ブロックチェーンのAPIを呼んだり、ウォレットのAPIを呼んだりすることしかできません。楕円曲線暗号は知っているのにRSA暗号は知りませんし、デーモンは知っているのにプロセスは知りません。トランザクションと聞けばブロックチェーンのトランザクションが先に思い付きます。もちろんSQLは知りません。それなのに自分が何かクールなことをしていると勘違いしています。え、Solidityも書ける？ああ、自分がクールじゃないと気付いたから周りのエンジニアとの差別化を図ったんだよね。わかるよ。でも、小手先で見栄えだけよくする様は、Web3起業家ワナビーとマインドが一致しています。頑張ってください。」
■ Web3ヤー「〇〇チェーンは高スループット（もしくは高TPS、高スケーラビリティ）！」
解答「〇〇チェーンが高いTPSを記録しているのは、分散性を犠牲にしているからです。ブロックチェーンとは呼べません。どこかに単一障害点があるので不安定でよく止まります。分散していないので、ゲンスラーの手にかかれば瞬殺されるでしょう。」
※別解「高スループットなのはいいけど、その分増えるデータ容量はどうすんの？将来的に何十～何百テラバイトにもなるチェーンデータを非中央集権的に持続的に分散管理できるとでも思ってるの？結局は、Googleのようなところに集中しない？」
■ Web3ヤー「SolanaやPolygonは分散してる！！」
解答「SolanaやPolygonはコンセンサスに参加できるノードを制限しています。ちなみにSolanaのバリデータノードは走らせるためだけに一年で数万ドルかかるので一般人には手が出せません。また、Polygonは人が管理するブリッジに全ユーザーの資産をロックしているので、実質中央集権です。バリデータは偽装工作です。もちろん証券でしょう。」
※別解1「Polygonは速いのはいいけどさ、reorg（チェーン巻き戻し）多すぎない？まだ少しの人にしか使われてない黎明期に、そんな調子で大丈夫なの？でもバグった自民党NFTがデプロイされてキッシーが無限ミントされたおもしろチェーンだから、消えたりしないでね。」
※別解2「Solanaはトランザクションの9割は同期用のトランザクションだから実際のTPSはずっと低くない？例えるなら、モバイル事業者が一日10000通話達成したって宣伝しながらそのうち9000通話がその事業に必要な内線ってことでしょ？はなしもりすぎ。お前の父ちゃんアーフロ。」
■ Web3ヤー「ADA Cardanoしか勝たん！」
解答「今もこんな養分いるんですかね。Cardanoはプロジェクトの開始時から世界中のクリプト民から嫌われている稀有なプロジェクトの一つです。日本では反社との接点が報道されるなど真っ黒なブロックチェーンとして知られています。SolanaやPolygonとともにSECから証券と名指しされましたが、反論の余地はないでしょう。技術的にも、UTXOモデルを採用したCardanoにスマートコントラクトの未来はありません。」
■ Web3ヤー「リップル！」
解答「頑張ってください」
■ Web3ヤー「NEM、Symbolが来る！」
解答「君たちは、良い人そうだし、駆け出しエンジニアと繋がりたそうですね。君たちの純粋な眼差しを見ると、わたしは胸が締め付けられます。少なくとも来世では幸せになれるでしょう。」
■ Web3ヤー「Astar大好き！」
解答「君たちはNEM勢と同じ顔をした若い世代です。英語難しいから日本人がたくさんいるAstarに来たんだよね。わかるよ。はぁ、みんな揃って、優しいのに彼女いない顔をしていますね。来世では幸せになれるでしょう。」
■ Web3ヤー「IEO！」
解答「IEOはメチャクチャです。規制の緩い資金調達手段は、売り抜け目的の悪徳プロジェクトが養分を狩る場にしかなっていません。チャートを見る限り今年日本で行われたIEOはすでに全てが死んでいます。今後も触らぬが正解でしょう。しかし、それでも触りにくる養分は集まってしまうので、雰囲気で祭りになりやすい半減期前に、何らかの規制が求められます。」
■ Web3ヤー「NFTを使えば画像の無断コピーを防げる！」
解答「防げません。ふつうにコピーできます。」
■ Web3ヤー「NFTによってあらゆる電子データを所有できるようになった。革命だ！」
解答「NFTの所有と、法的な所有は別です。有体物ではない電子ゴミに所有権もクソもありません。」
■ Web3ヤー「NFTが盗まれても保険があるから大丈夫！」
解答「ブロックチェーン上では、成りすましが容易にできてしまうため、盗まれたふりも紛失したふりも簡単にできます。そのような保険サービスは持続できないでしょう。そもそも代替不可能なNFTの金銭的価値を測るのは容易ではありません。」
■ Web3ヤー「ブロックチェーンゲームなら、ゲームの資産がブロックチェーン上にNFT化され永遠に残るから、たとえゲームがサービス終了してもあなたの資産は売却できる！」
解答「ブロックチェーンが無くなる、もしくは止まったら全て思い出になるのは変わりません。」
※別解「サ終したゲームの資産って誰が買うんすか？」
■ Web3ヤー「STEPNのような〇〇 to Earnは革新的！」
解答「それはポンジスキームです」
※別解1「あれれ、STEPN息してなくない、ｳｫｳ、ｳｫｳ？」
※別解2「去年は滑稽だったなぁ、STEPN起動しながら歩いてる人たち。ペースが崩れるとトークンがもらえないからみんな同じ歩き方でさ。まるで朝鮮人民軍の軍事パレードなんだ。資本主義も共産主義も、行き過ぎれば同じってハッキリわかんだね。」
■ Web3ヤー「ブロックチェーンはゲームと相性が良い。ミッションクリアの報酬を仮想通貨でもらったり、アイテムをNFTでもらえるんだ。参加者同士で交易もできるから仮想世界で経済圏をつくれるんだ！」
解答「チート使って人間のふりして24時間稼働して金稼ぐbot天国になります。ブロックチェーンゲーム（BCG）は、いかにプロトコルをハックして稼ぐかを追究する数字ゲームに還元されるので、純粋にゲームする人間は養分になるでしょう。ポケモンGoのような従来のゲームならさほど大きな問題にはなりませんが、チートでお金を稼げるようになる、しかもそれが他プレイヤーに損を押し付ける形でなので、すぐさま深刻な問題になるでしょう。」
※別解1「掛け金を払ってそれを超えるリターンを期待するゲームは、ゲームではなくギャンブルです。今日からBCGのGはギャンブルのGってことにしましょう。」
※別解2「最近サッカーのBCGを始めましたが、数字比べゲームでした。いつになればサッカーができますか？」
つづく
シンプルでわかりやすい
GitHubのStar数はwireが一番多いですが、我々はfxを採用しました。
今回はgo開発でDIを導入したお話でした。
当初の目的は全て達成できており、大きなハマりもなく快適に開発出来ています。
オブジェクトの生成処理を一元的に管理する意義は大きく、稼働確認を一発すれば初期化に伴う実装ミスはほぼなくなりました。
また副次的な効果として、モジュール間の依存関係を意識することで、インタフェースが洗練された印象があります。
結果、様々な言語のDIコンテナが目指すところである、インターフェースと実装を分離して抽象度を高め、変更容易性を向上するという点を達成できました。
go開発でDI導入を検討中なら、uber-go/fxを選択肢の一つとしてお考えになってはいかがでしょうか。
現状、コンストラクタインジェクションで特に困っていないけどモジュールの数が多くなると違ってきたりするのだろうか？
せっかく「わかりやすいVue」という路線で人を集めていたのに、script setupの登場で台無しになってしまった感がある。 そして数多のVueを志した人たちの首を刈り取ったのではないか。
Evanも言っていたではないか、「Composition APIは複雑なコンポーネントを整頓するのに役立てるAPIである一方で、考えなしに使うと余計な混乱を招く」「Vue3のOptions APIで満足しきれなかった人のためのComposition APIなのだ」と……出典がどこなのか全くわからないし記憶を捏造したかもしれないが
かっこいいからとかじゃなくて愚直にOptions APIを使うのはいいぞ。
2023年6月13日開催の設計コミュニティイベント「現場から学ぶモデル駆動の設計 第24回」で発表する資料の説明です。
美少女ゲーム業界の人から、20代後半から30半ばまではWindows所有率が低いけど、その下はAPEXとかでPC所有率は上がってるから、その層が働き始めるまで会社が潰れなければ、美少女ゲーム業界も底から浮上するという分析が興味深かった
PC少ない空白地帯があるのね
ただ作り手も高齢化してて、若い創作好きは美少女ゲームじゃなくて別ジャンルに行ってるだから、どうすりゃ若返りできるのかな、という課題はあるそうで
それこそYoutube、TikTok、ASMR、同人CGなど、昔よりもメディアの選択肢が多いだろうからなあ
Macしか使いたくありませんな世代は確かにそのぐらいかも。
とはいえ、今あえて美少女ゲームやりたいか？ っていうと微妙な気はするのだが。
最盛期と思われる2000年代でさえ、「紙芝居ｗ」とか言われてたような。
そもそもニーズがあればSteamなりスマホゲーなりで参入を果たしていた気もする（R18はともかく）。
ニーズは微妙な気がするが。
というか、スマホゲーやブラウザゲー（艦これ、アズレン、ウマ娘etc...）でニーズは吸収されているので、あえてクラシックスタイルの紙芝居ゲーをやりたい・作りたいとはならない気がするな。