表題のとおりなんですが、私は仕事のスタイル上、1〜2年くらいで現場を移っていて、とくにスタートアップだとこうしたガイドラインの類が存在しないことがあるので、毎回（要請があれば）そのチームや状況に特化した形で書いてきました。これまではその都度イチから書いていたので、どこかにまとめておきたいと考えて、GitHub に載せておくことにしました。
■ メリット1 作らない機能についてキッチリ議論できる
一般的な一覧には“作る機能”しか記載しませんが、FMには“作らない機能”も含まれます。そのため、「リクエストされたけど作らない機能も含めて、ここに載っているものが全てです。この時点で漏れている機能があれば言ってください。」とコミュニケーションできます。「作る機能」ではなく常に「作らない機能」で議論が紛糾するため、この方式は大きな威力を発揮します。
■ メリット2 機能の優先順位（実現のステップ）がわかる
FMは“機能の優先順位”がついているので、「システム全体でこれだけの機能があります。とはいえ、段階的に実現していくので、まずはこの機能から作成します。来年時点ではこれだけの機能しかありませんが、業務まわりますか？」と時間軸を意識したコミュニケーションが可能になります。
■ メリット3 機能全体を俯瞰できる
一般的な機能一覧は証跡とすることを目的としているため一覧性など気にしませんが、FMは機能全体を俯瞰するため“一覧性”を高めています。実はこれが重要で、全体像が見えると心理的な安心感が高まるのです。常に全容が把握しやすい状態を作ることが、コミュニケーションのツボであり、この方式の狙いです。
強磁性体と反強磁性体の特性を併せ持った「第三の磁性体」として存在が期待されていた「Altermagnetic」(アルター磁性体)が初めて確認されました。アルター磁性体は、新種の磁気コンピューターの製造などに役立つことが期待されています。
研究チームは光がどのようにテルル化マンガンに跳ね返るかを測定し、結晶内部の電子のエネルギーと速度を測定しました。これらの電子をマッピングしたところ、アルター磁性体のシミュレーション結果とほぼ一致することが明らかになっています。電子は2つのグループに分かれることで、結晶内部での電子の異常な動きを可能としており、これがアルター磁性の特性の源になっていると研究チームは指摘しました。
科学系メディアのNew Scientistは「アルター磁性体の特性を用いることで、コンピューターのハードディスクドライブ(HDD)の記憶容量を増大させることができる可能性があります。市販のデバイスには強磁性体材料が詰め込まれているため、外部磁場の干渉に弱いという特性があります。アルター磁性体の場合、既存のものよりも高密度に磁性体材料を詰め込むことができるようになる可能性があります」と記しています。
AI 環境が目まぐるしく変化する昨今において、デベロッパーは大規模言語モデル（LLM）を使用するアプリケーションを構築するうえでさまざまな課題に直面しています。特に、従来から LLM の実行に必要だった GPU の不足は深刻なハードルとなっています。この投稿では、デベロッパーが Google Cloud のフルマネージド開発環境である Cloud Workstations 内で直接、CPU とメモリ上でローカルに LLM の力を活用できる新しいソリューションを紹介します。このチュートリアルで使用するモデルは Hugging Face、具体的には「The Bloke」のリポジトリにあり、CPU または低電力 GPU で実行できるようにするための量子化手法に対応しています。この革新的なアプローチにより、GPU が不要になるだけでなく、シームレスで効率的なアプリケーション開発の可能性も開かれます。「量子化モデル」、Cloud Workstations、localllm という新しいオープンソース ツール、一般提供リソースを組み合わせて使用することで、十分な機能を備えた開発ワークステーション上で既存のプロセスやワークフローを活用して、AI ベースのアプリケーションを開発できるようになります。
■ 主な機能と利点
GPU なしでの LLM の実行: localllm を使用すると、CPU とメモリ上で LLM を実行できるようになるため、不足状態の GPU リソースを使用する必要がなくなり、パフォーマンスや生産性を損なわずに LLM をアプリケーション開発ワークフローに組み込むことができます。
生産性の向上: localllm では、Google Cloud エコシステム内で直接 LLM を使用します。このインテグレーションにより開発プロセスが合理化され、リモート サーバーのセットアップや外部サービスへの依存に伴う複雑さが軽減されます。そのため、GPU の管理が不要になり、革新的なアプリケーションの構築に集中して取り組めます。
費用対効果: localllm を利用することで、GPU のプロビジョニングに伴うインフラストラクチャ費用を大幅に削減できます。Google Cloud 環境内の CPU とメモリ上で LLM を実行できるため、リソース使用率が最適化され、結果として費用が削減され、費用対効果が向上します。
データ セキュリティの向上: LLM を CPU とメモリ上でローカルに実行することで、機密データを管理下に置くことができます。localllm を使用すると、データ移転とサードパーティのアクセスに伴うリスクを軽減して、データのセキュリティとプライバシーを強化できます。
Google Cloud サービスとのシームレスなインテグレーション: localllm は、データ ストレージや ML API などのさまざまな Google Cloud サービスと統合されるため、Google Cloud エコシステムの可能性を最大限に活用できます。
shadcn/ui compatible react aria components that you can copy and paste into your apps. Accessible. Customizable. Open Source.
shadcn/ui と互換性のある反応 aria コンポーネント。コピーしてアプリに貼り付けることができます。 アクセス可能。 カスタマイズ可能。 オープンソース。
WindowsやMacなどのデスクトップPCでVisual Studio Code（以下VSCode）を利用して開発をする場合、同じローカルマシン上でDockerコンテナのLinux環境を起動し、VSCodeのターミナルで接続して操作することは、開発環境としてよくあることだと思います。
これと同じことをWebブラウザ版のVSCodeでも実現する、すなわちWeb版VSCodeが同一Webブラウザ上にWebAssembly化したDockerコンテナを起動し、Web版VSCodeからローカルマシンとして接続し利用できる、実験的実装を実現したVSCodeの拡張機能「vscode-container-wasm」が登場しました。
この開発をオープンにしないという考えが自分にフィットしている、そのため自社で公開しているオープンソースは基本的にこの考えを適用している。
理由としてはオープンな開発は負担が大きすぎると感じているのが一つある。小さな会社はリソースが少ないため、オープンな開発をやっていくのはとてもむずかしい。
もう一つの理由は、なにかあればパッチではなく、フォークして開発してもらうという方針を取りたいというのがある。自分たちでコントロールできる範囲で開発していきたいう考えが強いからだ。
開発をオープンにしないオープンソースという考えは、小さな企業がオープンソースを公開するときの方針の一つとしてはありだと思う。
状態を持たない処理ならStaticでええやろという話は同意できるけど、それをもって時代がStaticおじさんに〜は流石に意味不明。
目次
- タスク把握は諦めた
- 定点観測としての隔週1on1（30分）
- その人のキャリアとライフ（人生）を知る
- みんなの前で褒める
- 「僕の時間はすべて君たちのためにある。忙しいとか気にするな。使い倒せ」
- 会社の（人事）制度や仕組みについて、理由もセットで説明する
- 自社の魅力と会社（と僕）が「できないこと」を説明する
- 本人と話し合いながら適切な目標設定をする（挑戦項目を入れる）
- 許容できる失敗を想定しておく
- （必要なら）気軽に頭を下げる
- 警察官、裁判官として適切に機能する。意図も説明する
- 評価に対する基本スタンスを伝える
- 方針やスローガンなど「良い感じの話」を月に一回以上話す
- ときどきプレイヤーとして圧倒的なパフォーマンスを見せる
- 理屈を持ってたくさん（量）のフィードバックする
- そもそも、マイナスなことを言わなくて良いように日々の仕事をやらせる
- そもそもMBOなどの「目標制度」を誤解させない
- 有給休暇の話題は”こちらから”出す
- 期末にひとりづつメッセージを送る
- おまけ：判断や指示に、すべて理由を説明できるようにしておく
米国の研究機関であるAperture Internet Laboratoryは、Linuxで動作する中国のインターネット検閲システム「グレートファイアウォール」（Great Firewall、GFW、金盾）をオープンソースで実装したシステム「OpenGFW」を発表した。このシステムは家庭用ルーターで使用可能なほど柔軟で使いやすく、GFWを個人レベルで実現することを目指している。
OpenGFWは、IPとTCPのデータを完全に再構築する能力を持ち、HTTP、TLS、DNS、SSHなどのネットワークプロトコルを解析できる。特に、Shadowsocksなどの完全に暗号化されたトラフィックの検出機能や、Trojan-killerに基づいたTrojanプロトコルの検出機能が含まれている。
IPv4とIPv6の両方をサポートし、ネットワーク負荷を複数のコアで分散処理する機能や、exprに基づいた強力なルールエンジンを搭載している。Webベースのインタフェースや機械学習を用いたトラフィック分類機能の開発も進行中である。
ソフトウェアやクラウドサービスなどの設定に用いるコンフィグレーションファイルはどんどん複雑になってきており、利用者が望む詳細な設定を、一般的なコンフィグレーションファイルのフォーマットとして使われているJSONやYAML、XMLプロパティリストなどの形式で正確に記述することは難しくなってきています。
Pklはそうしたコンフィグレーションを正確かつ分かりやすく記述するために開発された、特定目的用のプログラミング言語だと説明されています。
純粋な「個人ブログ」、「日記」というものはもうGoogleはインデックスしない。
「しない」は言い過ぎかもしれないが、ほとんどしない。いつからだかはよくわからない。よくわからないが、おれがそれを実感したのは、去年「ジャパンモビリティショー」に行ったときのことだった。いや、正確には「行く前」だ。いったいどんなショーなのか、どのくらい混んでいるのか、どんな雰囲気なのか、ちょっと検索してみたのだ。終わりごろに行ったので、いくらかわかるだろう、と。
しかし、出てくるのは公式サイト、ニュースサイトの記事（といっても、プレスリリースだけみたいなのも多い）、出展者の公式サイト……。もちろん、「感想」や「日記」というフレーズを足してみたりしても、もう個人の日記なんて出てこないんだよ。なんかムキになって探したけど、本当に出てこなくて、「ああ、もう本当にインデックスされねえんだな」と思ったよ。結局、Xで入場列の長さのポストを見たくらいだ。
「monaspace」は、GitHubがプログラミング用途に開発したモダンな等幅フォント。ライセンスは「OFL-1.1 license」で、現在「github.com」のプロジェクトページから無償でダウンロードできる。
本フォントは比較的縛りの緩い「OFL-1.1 license」ライセンスとなっているので、日本語フォントと組み合わせた派生の登場も期待できそうだ。今後の展開に期待したい。
コードエディタのVisual Studio Code（以下、VSCode）は2024年1月のアップデートで、「Hey Code!」と音声で呼びかけると、Copilot Chatが起動する新機能が追加されたことが明らかになりました。
日本放送協会(NHK)は、総務省の会合において、将来NHKインターネットサービスの必須業務化が改正放送法で決まった場合の基本的な考え方を説明。負担のあり方について、「必須業務として実施する以上、インターネットでの提供についても、受信契約の対象として相応の費用負担(受信料)をお願いすることになる」との考えを示した。NHKプラスのような動画サービスだけでなく、NHK NEWS WEBなどの報道サイト等も対象となる。なお、テレビ受信料を支払っている場合は、追加の負担なくネットサービスを利用できる。
負担のあり方については、「必須業務として実施する以上、インターネットでの提供についても、受信契約の対象として相応の費用負担(受信料)をお願いすることになる」と説明。
そして、「その際は、テレビを設置し、NHKの放送を受信できる環境にある方に契約をお願いする従来の受信料制度との整合が重要と考えている」、「いわゆるペイウォールのような、料金を支払う事で初めて利用できるかたちとは異なる方法で実施する想定」と話した。
スマートフォンやPCなどの通信端末を取得・保有しているだけでテレビ設置した場合と同等に考えるのではなく、あくまで、「視聴する意思が外形的に明らかになるような何らかの積極的な行為が費用負担の要件」としながら、費用負担の方法の詳細については「技術的な課題も含め、現在様々な方法を検討中。時期が来たら、改めて説明をしたい」と述べた。
OSCHINA の方針で 1 月 31 日の閉鎖を予告していたスラドと OSDN だが、一転方針が変更されサーバーを停止せずに受け入れ先を募集することとなった。
これにより、両サイトとも当面はこれまで通りアクセス可能だ。ただし、スラド編集部はアピリッツとの契約で更新作業を続けてきたが、契約は 1 月 31 日で終了となるため、更新に関して本日をもって停止する。なお、保守や管理のために何らかの案内等が更新される可能性はある。
スラドまたは OSDN の受け入れを希望する企業の方は、編集部 (osdn_api@appirits.com) までご連絡いただければ、詳細が決まり次第ご連絡差し上げる。末筆となったが、OSCHINA への譲渡後 1 年以上にわたって編集部との契約を続けていただき、引き続きメールアドレスも使わせていただいているアピリッツに感謝したい。
「読む人のことを考える」
これだけ。
僕は、ドキュメントを読むのが苦手。すぐに混乱する。
ひとつの段落が長いと混乱する。正確に書いてくれているんだろうけど、書き手目線で細かくばーって書いてあって、読み手がそこから自分の目的の情報を探し出さないといけない状態だと混乱する。
あと、ページの階層が深かったり、リンクでジャンプしまくったり、用語がぶれていたり、文章が複数の意味に捉えられる書き方になっていたりすると、混乱する。
他にも、このあたりに気をつけてる
- いきなり詳細の話から始まると混乱するので、全体を説明してから詳細に入るように書く
- 段落は長いと読めないので、3〜5行にする
- 違う意味にとられないように気をつける（赤いシャツのシミ、は、シャツの赤いシミ、ともとれるから、シミが赤いシャツについている、って書くとかそういうの）
- 受動態だと主語が分かりにくいので、能動態にできないかを考える
- 二重否定を避けられないか考える
- 複雑な説明は、文章だけじゃなくて、図を描く
- ページ階層が深くなりすぎないようにする
- リンクは文章中よりも、参照リンクの項目にまとめたほうがいいかどうかを考える
- 同じことをできるだけシンプルに書けないかを考える
- ここに書かなくてもいい情報を書いてしまわないように気をつける
とか、そういう風にして、自分が読んでも混乱しないドキュメントにしてる。
ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。
ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術力を求めなければ採れうる人材の幅は圧倒的に広くなる。
エンジニアリングに話を戻して具体的にするならば、あるチームの仕事の中に社内で使っているサードパーティ・ライブラリの基盤に新機能追加のPRを出すタスクと、単にアプリケーション側でフレームワークの新しい機能を使うように書きかえるだけのタスクが同列に存在しているような状態を想像するといい。全員が同じレベルで全てのタスクに着手できない状態である。開発者ごとに相対的な認知負荷に対する許容範囲の差分があり、メンバー間の認知負荷の差分が結果的に技術的負債を生み出す原因になる。また、この手の負債は属人性がボトルネックになることで回収されないままになる。*2
これらは、いずれにしても同一のチームで求められるクリエイティビティのレンジと、個々人が対応できる認知負荷の容量のバラつきが大きすぎることが原因である。認知負荷は他者の発揮するクリエイティビティの発露によって生まれる結果であり、この差分が大きくなっている箇所をチームとして分割せねばならない。
その際には、育成や指導でメンバーのクリエイティビティの下限をどうにかして上げようとするのではなく、構成されるメンバーに応じて上限にリミットをかけるためにチームを分割・構成するべきだ。
プロパティベーステスト（Property based testing）は、テスト対象のコードが満たすべき特定の特性や条件（プロパティ）が、さまざまな入力値に対して一貫して成り立つかどうかを確認する方法です。
- 自動化されたテストケース生成
- エッジケースの探索
- 効率的なテストプロセス
- 継続的なテスト更新
面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。
書類からある程度ペルソナができていて、その検証作業のような気がします。
1時間やそこらで人間の深いところなんてわかんないですし、騙そうと思えばいくらでも騙せると思いますし。
IT企業の採用において、「迷ったら見送る」「採用基準は下げない」というのが鉄則みたいです。
■ スキル
- Githubアカウント見て、コード見るのが一番早くて安心感がある
- 論より証拠
- 仕事より雑に書いてたとしても、それでもレベル感は把握できる
- アーキテクチャー/テストの意識があるか
- ただ特定のアーキテクチャーへの思想が強すぎるとか、TDDを絶対視してるとかは危ないかも
- 原理主義の傾向がある人は避ける
■ コミュニケーション
- HRTの原則で行動できているか
- 有害性が高い人は真っ先に弾きたい Brilliant Jerk（優秀だが攻撃的で周りに悪影響を与える人材）は避ける
- 受動的すぎる人もなるべく避けたい
- が、エンジニア採用だと、優秀な人ほど面接の印象が受け身に見えがち
- 実績で判断するのが良いか
- 質問に対して、適切な回答が来る、というのは大事
- 質問がわかりづらいパターンもあるので、そこはふりかえる
■ カルチャーマッチ
- その人のやりたいことと会社&ポディションがマッチするか
- 担当することになるプロダクトに興味あるか
- 必須条件ではないが、あった方が本人のモチベになるので結果的には良いと思う
- 単純にノリが合いそうかどうか
- 多様性の担保も大事だが、あまり攻めすぎると早期離職や人間関係悪化が起こる
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。
TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。
■ トランザクション境界
トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。
だから、トランザクション境界を作ってDBを小さく保てば、そこに対するサービス（アプリケーション）も小さく保てるかなと。サービスが小さければその中でSQLの力を活かした素朴なコードを書いても、そこまで複雑にはならないんじゃないかなという気持ち。
トランザクション境界があると、それを超えた整合性の伝搬には非同期処理を使う必要があるなど、別の複雑さを持ち込んでしまうけど、DBが一手に担ってくれてた複雑さをどう分散させるか、そのあたりをうまくやることに今は興味がある。
■ ユビキタス言語
ユビキタス言語は、とても意識している。PdMが喋る言葉から、ドキュメントはもちろん、プログラムの中まで同じ言葉を使うようにしている。
たとえば「薬品」はプログラムの中でもそのまま「Yakuhin」となっている。バックエンドで変数名などに漢字を使うのは予期せぬ問題にぶつかりそうだから、ローマ字にしてる。ちなみに、フロントエンドでは日本語コンポーネントを使ってる。ぱっと見て理解できる漢字のすばらしさよ。
■ 小さく保つ、名前にこだわる、それで複雑さに立ち向かう
という感じで、今は、影響範囲を小さく保つことと、名前にこだわることに興味を持っている。いちどに気にする範囲を小さく保って、レイヤーを分けて、意識しておくべきロジックは凝集させて、変数や関数やモジュールの名前にこだわる。1つの関数をできるだけ小さくする。依存の向きは一方向にする。イミュータブルにする。
スタートアップ的な開発と技術的負債の話、スタートアップからの案件相談とか聞いてて思うのは、安定化・リファクタリング期間を明示的に積む経営判断をすれば済んでる話を、現場レベルで技術的負債が生まれる前に完璧なアーキテクチャを組もうみたいなアプローチをして爆散してる印象なんだよな
まあ、このあたりの話、単に経営者が技術に疎いとかそういう話ではなく、CTO的な人間がそういうマネジメント概念を持ってないケースもあり
Ryan Brewer氏は、「SaberVM（Saber仮想マシン）」を1月18日（現地時間）に発表した。
SaberVMは関数型言語のコンパイラバックエンドで、さまざまな用途での実装が可能な抽象スタックマシンであり、クロージャ変換およびホイストされたCPSコードを取り込んで実行するか、AOTがネイティブバイナリにコンパイルして実行される。
malloc/freeスタイルの内部メモリ管理システムを備えたアリーナであり、寿命が終了するとアリーナのように解放されるリージョンと、引数を受け取らず実行に失敗した命令がプログラムをクラッシュさせることなく、例外ハンドラにジャンプする例外という、2つの主要なシステムによって構成されている。
SaberVMでは、安全性、表現力、移植性、信頼性を目指しており、全体的には約半分の実装が完了しているという。
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。
影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。
コンウェイの法則
「システムを設計する組織は、その組織の構造をそっくりまねた構造のシステムを設計してしまう」という法則。
例えば、1つのソフトウェアを複数のチームが協力して作るとき、そのソフトウェアはチームと同じ数のモジュールに分割された内部構造を持つシステムとして設計されてしまう。
コンピュータ科学者メルヴィン・コンウェイ氏により提唱された。
パレートの法則
「全体の数値の８割は、全体を構成する要素のうちの２割の要素が生み出している」という法則。
イタリアの経済学者ヴィルフレド・パレートが発見した。
グッドハートの法則
「計測結果が目標になると、その計測自体が役に立たなくなる」という法則。
数値目標が重視される組織では、組織の構成員はその数値目標を達成することを優先し、本来の目的を見失い、場合によっては不正な手段に走ってしまうことに対する警鐘が込められている。
英国のエコノミストであるチャールズ・グッドハート氏により提唱された。
パーキンソンの法則
「第1法則：仕事の量は、その仕事を完成させるために与えられた時間をすべて満たすまで膨張する。第2法則：支出の額は、収入の額に達するまで膨張する」という法則。
元は英国の官僚制を観察して導かれた経験則だが、コンピュータに適用されたバリエーションとして「データ量は与えられた記憶装置のスペースを満たすまで膨張する」なども存在する。
英国の歴史学者・政治学者シリル・ノースコート・パーキンソンの著作「パーキンソンの法則：進歩の追求」で提唱された。
ブルックスの法則
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則。
フレデリック・ブルックス氏の著書「人月の神話」で提唱された。
リトルの法則
「自分が行列に並んだときに、1分待って、前に並んでいる人数を後ろに並んでいる人数で割ると、何分待つかが予測できる」という法則。
リトルの法則は、ソフトウェアの性能テストにおいて応答時間などの見積もりや改善に応用できる。ケース・ウェスタン・リザーブ大学にいたジョン・リトル（John Little）氏によって証明が発表された。
ピーターの法則
「能力主義の階級社会においては、誰もがその能力の極限まで出世してしまう。例えば有能な平社員は無能な中間管理職に出世する。そして最終的には各階層が無能な人間で埋め尽くされてしまう」という法則。
教育学者ローレンス・J・ピーター氏とレイモンド・ハル氏の共著による書籍で提唱された。
ハインリッヒの法則
「1件の重大事故の背後には、重大事故に至らなかった29件の軽微な事故が隠れており、さらにその背後には300件もの危険な状況、いわゆるヒヤリハット（ヒヤリとしたりハッとしたりする危険な状態）が隠れている」という法則。
1920年代にアメリカの損害保険会社に勤めていたハーバード・ウィリアム・ハインリッヒ氏に由来する。
ピーク・エンドの法則
「人はある出来事に対し、感情が最も高まったとき（ピーク）の印象と、最後の印象（エンド）だけで全体的な印象を判断する」という法則。
心理学・行動経済学者のダニエル・カーネマン氏が1999年に発表した論文の中で提唱された。
ホフスタッターの法則
「物事はつねに予測した以上の時間がかかるものである。あらかじめホフスタッターの法則を計算に入れていたとしても」という、複雑な作業にかかる時間は正確に見積もることができないことを示す法則。
ダグラス・ホフスタッター氏の1979年の著書「ゲーデル、エッシャー、バッハ」の中で提唱された。
Easy: 手数の少なさを重視（そのかわり覚えることが増え、特定の状況には強いが他には弱い設計になる）
Simple: 覚えることの少なさを重視（そのかわり手数が増えたり、自分で組み合わせたりしなければならない）
この二つを混ぜると設計の軸がぶれるので、分けることが重要
技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck
（言及いただいたので補足します）Simple と Easy は軸が違う（それぞれ対極は Complex と Hard）ので、対象が十分に小さければ両立できないわけではないのですが、多くの場合では結局トレードオフになります。二つを意識して分けないと（例えば層を分ける）、どっちつかずの設計をしてしまいがちです
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。
本書で取り扱われるトピックには、次のようなものがあります。
- Four Keys メトリクスの計測と可視化の実践
- アーキテクチャ適応度関数（architectural fitness functions）の考え方を用いてアーキテクチャが目的を満たしているかを検証する方法やヒント
- モジュール性成熟度指数（Modularity Maturity Index:MMI）を用いて技術的負債を計測する方法
- DevOps文化に組織が移行できているかを測るのに役立つメトリクス
- ビジネス目標と結びついた適切なKPIからソフトウェアアーキテクチャメトリクスを導く方法や実践
- メトリクスベースのフィードバックループを実践して保守性を保つ方法
Lumeの紹介ゲーム開発ひいてはクライアントサイドの開発において「クリーン」かどうかは正直けっこうどうでもよく、設計すべき一番のポイントは「制御フロー」にあります。
ところがゲーム開発の場合は、こういった特徴を一般化してフレームワークに追いやれるか? というと そういうわけでもない。
「ゲーム」と一口に言っても色々で、アクションゲーム的なものとRPG的なものではかなり中身の性格は違っているし、 ゲームでは「ドメインロジックが主」というよりもむしろ、「プロジェクト固有のViewコンポネを自前でつくっていく」ことの方にどう考えても重みがある。
ゲ開発で、そのゲーム固有の色々なものをつくる、ということは、imgタグそのものを実装する、という姿が近いとおもっている。つまり、人間に理解しやすい抽象化されたデータよりも、もっと細かくて複雑なフレーム毎の見た目の変化をプログラムしていくことになることが多い。
Viewコンポネの実装の詳細はいつも複雑なので、それを外から見るともっと抽象的で扱いやすいインターフェイスにしていく必要がある(imgタグしかり) のはゲームも別に変わらない。違うのは 部品そのものを自作することがゲーム開発の主な関心事になってくること。HTMLであれば基本は 標準化されたパーツを組み合わせて集約させたものを扱うのだけど。
「ドメインロジックとプレゼンテーションの分離」はゲームであっても普通にやっといた方が良いであろう。抽象的なデータと Viewの境界は疎結合になっていないとまじで困る。 「キャラクターのデータ」 と、「画面に適用させたい対象」との関連性は、1:1 ではないし、まだ画面には出てないけどデータを参照したい、みたいなケースは死ぬほどあるからである。 つまるところMVCが言っている「Model」というのは、遷移する状態全てではなくて、「アプリケーション固有の状態」のことだからである。
しかし、なんか強力なフレームワークとか足回りを前提とした設計パターンをあてはめることはゲームでは単に手間になる。
Viewへのマッピングの自動化はあきらめた方が生産性も保守性も柔軟性も高い。
重要なことは、MとVを分けること。それからイベント発火からの制御フローを明確にすること。
最も有名なWebアプリケーションフレームワークの1つである「Ruby on Rails」は、もともと37signals社が社内向けに開発したフレームワークでした。
現在ではGitHubやShopifyなど大規模なWebサービスを支えるRuby on Railsも、登場初期には「スケールしない」という批判にさらされ、また競合となるフレームワークが登場するなどの経緯を経ています。
こうしたRuby on Railsのこれまでを、作者であるDavid Heinemeier Hansson（以下、DHH）氏や関係者が振り返る動画「Ruby on Rails: The Documentaryが、昨年（2023年）11月に公開されました。
Ruby on Railsがどのような経緯で開発され、発展してきたのか。DHH氏やコアチームの発言によって紹介されています。この記事では、その内容をかいつまんで紹介していきましょう。
皆さんに長年ご愛顧いただいたスラドだが、残念ながらこの度終了する運びとなった。
アピリッツが OSDN を OSChina へ譲渡する際、スラドを分離して別の受け入れ先へ譲渡する対応をお願いしていたが、対応が進まないまま時が過ぎていたようだ。最近になって OSChina からスラドと OSDN を閉鎖する計画があると聞いた編集部が交渉したところ、分離してかまわないとの回答を得たのだが、日本側受け入れ先の都合が悪く、分離計画は頓挫してしまった。
スラドはしばらく更新を続けるが、1 月末にはサービスを停止する。データを保存したい方は早めに進めてほしい。
本書のテーマは「データモデリング」と「基幹系システム」です。
Web上で台頭しつつある新たなビジネスは，新たな基幹系システムを必要としています。一方，既成ビジネスでは，モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。
基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン，つまりデータモデリングがいずれの取り組みにおいてもカギですが，データモデリングが真価を発揮するには，その知識体系を現代的に仕立て直す必要があります。
本書では，「活動のシステム」と「経営管理のシステム」という線引きを導入し，2つの領域で異なる帳簿特性を踏まえて，分散／非同期／疎結合な基幹系システムのための実践的データモデルを詳説します。さらには，データモデル理論の基礎にも新たな光をあてて，論理削除，テーブル分割，履歴管理といった共通論点に解決の糸口を提供し，支持を得ているドメイン駆動設計との関係性を探究します。
2024-02-24発売か
[...]ただ、そこからどう捻れたのかわからないが、「Rustは低レベルに入門する最後のチャンスだ！」「Rustを勉強すれば低レベルを理解出来る！」という人間をTwitterで見て、さすがに舐めすぎではと思ったのでここではっきりさせておくと、お前らはRustを勉強しても意味ない。
Rustのありがたみを理解するには、CやC++を真剣に書いて、リソース管理の難しさを体験しなければいけない。あるいは、GCのある言語で難しいことをして、本来ありがたい存在であるはずのGCの挙動を理解しながらコードを書くことの不毛さを体験しなければいけない。そこまでやってはじめて、Rustを学ぶ価値が生まれてくる。彼らの言葉を借りるならば、低レベルを理解している人間にしかRustは価値ないんです。パターンマッチとか関数型のテイストだとか、そんなものが欲しいならばOCamlやScalaでもやればいいんです。わざわざこんな学習コストの糞高い言語を学ぶ価値なんかひとっつもないんです。がんばってください
FastSDCPUをノートパソコンに電源を繋いでAMD 8コアCPUターボブーストでフルスピードで計算させたらトータルでわずか19.36秒という高速っぷりw
標準のStable diffusionがいかにCPUで遅いかという事が分かってしまった。
20秒以下ならGPUなくてもそこまで困らないな・・・
ほー
パスワードの利用は、もはや時代遅れと考えられ、パスキーの利用が推奨されつつある。本記事では、パスキーへ移行することで得られるメリットや、その際の課題を解説する。
パスキーは公開鍵暗号方式の仕組みを利用している。Webサイトやアプリ、そのほかのオンラインサービスでアカウントを保護するよう、公開鍵と秘密鍵のペアが生成される。
秘密鍵は、暗号化された長い文字列としてデバイスに保存される。一方、それに対応する公開鍵は、GoogleやAppleのiCloudにあるパスワード管理システムのような、オンラインサービスのサーバーへ送信される。
ログインしようとすると、PINコードや指紋、ほかのデバイスを使ったスクリーンロックによる認証が要求される。パスワードを入力したり記憶したりする必要はなく、プロセスがより安全で利便性のよいものになる。
ログイン時には、サーバーからデバイスへ暗号化されたチャレンジが送られる。デバイスは秘密鍵でこれを復号し、サーバーへ送り返す。返信された値によって、認証に必要な秘密鍵と公開鍵のペアが正しいことが検証される。
■ パスキーの課題
[...]
・同じOSで動くデバイス間でのみパスキーを同期できる：ほかの記事で解説されているように、パスキーはOSごとに同期される。例えば、iOSデバイスとWindowsコンピューターを使っている場合、ユーザー体験は悩ましいものとなるだろう。異なるOSのデバイス間でパスキーを利用するには、QRコードを読み取ってBluetoothをONに切り替える必要がある。現行のパスワードの仕組みと比べても、さらに使い勝手は悪くなってしまう。
■ 10の原則
- (1) すべての要素を冗長化する
- (2) 自己復旧できるようにする
- (3) 調整を最小限に抑える
- (4) スケールアウトできるようにする
- (5) 分割して上限を回避する
- (6) 運用を考慮する
- (7) マネージドサービスを活用する
- (8) 用途に適したデータストアを選ぶ
- (9) 進化を見込んで設計する
- (10) ビジネスニーズを忘れない
ソフトウェアには大きく分けて2つの側面があります。気候問題の一部という側面、そして気候問題の解決 方法という側面です。
グリーンソフトウェアを開発し、普及させるためには、人材、標準、ツール、およびベストプラクティス からなる信頼できるエコシステムを構築する必要があります。まさにそれがグリーンソフトウェア財団の ミッションです。
■ 炭素
私たちは、ソフトウェアが気候問題の一部ではなく、気候問題解決のためのものになることを望んでいま す。これが、私たちがソフトウェアによる炭素排出量を削減することで気候に及ぼす負の影響を減らすこ とに重点を置いている理由です。
ソフトウェアは気候問題のソリューションにもなりえます。ソフトウェアはあらゆる産業や社会の脱炭素 化を加速させることができます。我々人類はグリーンなソフトウェアの開発とグリーン化のためのソフト ウェアの開発の両方に取り組む必要がありますが、私たちが注力するのはグリーンソフトウェアを開発す るためのエコシステムを構築することです。
グリーンソフトウェア財団は非営利組織で、ソフトウェア開発に携わる人々のために設立されました。私 たちの責務は、ソフトウェアによる排出量を削減するために開発者がすべき行動の正解を与えることです 。
■ 削減
私たちは削減に注力しています。相殺ではありません。大気中に排出されなかった1グラムの炭素と、相殺 された1グラムの炭素は同じではありません。明らかに望ましいのはまずに炭素を排出しないことです。
削減することは、相殺することよりも困難です。それは必然的に、より多くのリスクと投資を伴います。 リスクと軽減し投資へのインセンティブを増すためには、人材、標準、ツール、およびベストプラクティ スからなるソフトウェアの炭素排出量削減のためのエコシステムを構築する必要があります。財団のミッ ションは、そのエコシステムを育てることです。
■ 活動
私たちはソフトウェアの炭素排出量を削減する方法は次の3つだけだと考えています。
- 利用する物理的なリソースを減らす
- 利用するエネルギーを減らす
- エネルギーをよりインテリジェントに利用する
エネルギーをよりインテリジェントに利用するということは、より低炭素のエネルギー源を消費するか、 低炭素な未来への移行に資するように電力を消費することを意味します。
ソフトウェアの炭素排出量を削減するためにできることはすべて、上記の1つ以上のカテゴリーに該当しま す。財団のミッションは、ソフトウェア業界全体でこの3つがより多く行われるようにすることです。
恥ずかしながら、「グリーンソフトウェア」という言葉自体知らなかった。
調べてみると、Green Software Foundation なる団体があり、そのサイトによると、グリーンソフトウェアとは温室効果ガスの排出を削減するソフトウェアのことらしい。
正直、「温室効果ガスの排出を削減するソフトウェア」と言われても、リソース使用を抑えた作りのソフトウェア？ 富豪的プログラミングとは相容れない？ くらいしか考えが浮かばないのだが、これからこの言葉が流行ったりするのだろうか。
1️⃣ コードをより詳細化するコメント(lower-level comment)
2️⃣ コードをより抽象化するコメント(higher-level comment)
どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。
1️⃣ コードを詳細化するコメント(lower-level comment)
変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必要ではあるが、命名でカバーできる範囲が広く必ずしもコメントが必要ではないタイプになります。コードの実装詳細の説明もこちらのタイプに属すると思います。
2️⃣ コードを抽象化するコメント(higher-level comment)
主にクラスやメソッドなどのインターフェイスに残すタイプのコメントで、コードの直感性を高めます。インターフェイスを切る作業はコードを抽象化する作業ですが、命名などで伝えきれない抽象化された内容を自然言語でコメントとして補足し、直感性を強化します。抽象化の精度について本書では、「メソッドの利用者がそのメソッドの実装詳細を読まないといけない状態は利用者のコードリーディング時間を無駄に生み出しており、インターフェイスの果たす役割である抽象化に失敗している」と述べています。もっともなことですが、個人的には普段各レイヤーを縦横無尽にコードジャンプして色んな実装詳細を結局読んでいるため耳が痛い話でした。
良い抽象化が行われているインターフェイスには必ずコメントが必要になります。 良い抽象化を「複雑な実装詳細が隠蔽されてシンプルなインターフェイスが提供されていること」であるとした時、その抽象化を説明する手段として「コード」だけを用いると具体的かつ詳細的になりすぎて説明が不足します。言い換えると、命名だけで支えられるインターフェイスは、その抽象化が弱いことを示していると言えるでしょう。
本書では、自然言語を利用できる「コメント」が最も抽象化を体現できる手段と捉えて、コードを書き始める前に先にコメントを書く「コメントファーストアプローチ」を採用することで、抽象化の具合を点検し、より良いシステムデザインを導くことができると主張しています。[...]
【近況報告】
ご無沙汰してます。小林です。
しばらく発信を控えていましたが、近況についてご報告させてください。
実は、昨年8月頃にprimeNumber社の役員を急遽退任することとなりました。
ここで退任の理由を記載するのは控えますが、troccoの生みの親として本気で向き合ってきた結果、このような形となり無念です。
何よりも、私の作ったプロダクトをご愛顧いただいているお客様に、本当に申し訳なく思っております。
また、私が同社時代に立ち上げた勉強会 #DataEngineeringStudy についても手を離さなければいけなくなりました。
データ人材の育成には人一倍熱い想いを持っていたのですが、とても悔しいです。
いつもご視聴・ご参加いただいていた皆様には、深くお詫び申し上げます。
（勉強会自体は私抜きでまだ続けているみたいですが…）
そんな私ですが、今後はデータテック系のプロダクトを再び1人で作っていこうと思って地道に仕込んでます！
そのためにも一度データエンジニアとして現場に戻りたいと思い、現在はフリーでデータテック関連の開発やアドバイザリーもさせていただいていおります。
最近はもっぱらdbt触ったり、PdM+開発セットでのご支援もしてます。
（お仕事いただける方は是非DMください笑）
そして #DataEngineeringStudy はこのような形となりましたが、今後もデータエンジニアを目指す方へのご支援についても、熱い想いを持って続けていきたいと考えてますのでご期待ください。
辛い時期も長かったですが、現在は前向きに頑張っています。
そんな私を励ましていただける方、データテックについて語り合いたい方、（お仕事いただける方笑、）是非ご飯・飲みに誘ってください！
リファクタリングをプロジェクトとしてやったことありますけど、知見としてはリファクタリングをプロジェクトとしてやってはいけない、コードの品質で本当に困っていても、全てを諦めてそのまま運用し、仮に十分な工数が取れるなら品質の知見を活かして作り直したほうがよい、というのが得られました。
作り直した方が「早い」のではなく、現状塩漬け以外は不幸な未来しかない（ので動いている限り無視する、どうしようもなくなったら作り直す）、というかなり悲観的なやつですね。
「Object-Oriented Conference」は、オブジェクト指向についてあれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのカンファレンスです。
オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。
Object-Oriented Conference ではプログラミング言語の縛りを超えて、オブジェクト指向に関連するセッションであればなんでも OK！
セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。
オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！
動画配信してくれるかな？
JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。
典型例として、最近メーカーで多いのが、デリバリーの高速化・高頻度化対応の阻害です。
[...]
しかし、品質保証部門が、その変化に対応できずに、旧来のウォーターフォールプロセスを実質的に強制するような、長大な時間・コストを要する品質保証を強制し続けて、開発アプローチの改革を困難にしてしまう事例が、JTCにて今でも普通に見受けられます。
[...]さらにプロダクトの品質も低下させます。必要最低限の有限な開発リソース（コスト、時間、人）を、重厚長大な品質保証対応で浪費させて、本当に必要な品質の確保・保証のためのリソースを不足させてしまうためです。これは品質の向上・保証のために膨大なリソースと時間の投入を強制しているのに、逆に品質を悪化させているという、いびつな構図を生み出します。
求められる品質が大きく変わり、それに応じて開発の体制やプロセスの改革が求められているのに、権力を持った旧来の品質保証部門が改革をブロックしている状態は「品質保証部門の老害化」というべきものです。
プロダクトへの価値貢献ではなく、旧来のプロセスの権威化で自分たちの存在価値を確保している
過去の実績に基づいて構築した品質保証プロセスをトップダウンで守らせ続けることで、自分たちの影響力・権力を維持する傾向です。
一方で「今の自分達がこれからのプロダクトへの価値貢献に貢献できているか」という責任からは逃避します。
また、旧来の品質保証プロセスを、最新のプロダクト状況に合わせて改善することは、自分たちの能力不足を隠すために、暗に抵抗します。
本質的な品質理解を行わなず、旧来のメトリクスの数字で品質を判断する
ソフトウェアの品質が妥当か、本質的な判断を行わず、旧来のメトリクスの数字が基準以上かで品質判断する傾向です。
この傾向でありがたられるメトリクスの定番としては、テストカバレッジ、テスト密度、バグ密度、レビュー密度、レビュー指摘密度などがあります。
例えば、本質的にテスト設計が適切か判断できないため、テスト密度やバグ密度の数字が基準を満たしているかでテスト品質の判断を確定します。
プロダクトバリデーションを放棄して、プロセスバリデーションに偏重する
能力不足により、本質的に必要な品質の確保・保証（プロダクトバリデーション）に手を出せない状態です。かわりに、旧来のプロセスルール（ドキュメントテンプレート、構成管理、レビュー量、承認プロセスなど）の遵守をもって品質保証の判断を行う傾向を強めます。
能動的な品質理解を行わず、受け身で品質を判断する
能力不足により、自立して主体的に品質を評価できない傾向です。
自力で評価できないリカバリとして、自分たちが品質を理解できるまでの説明責任を、開発部門に負わせます。そこでは自分たちの能力不足で理解できないものは、開発部門の説明責任の不備に責任転化します。
開発のリードタイム高速化による品質改善を評価しない。品質ゲートによるバグゼロ志向に傾倒する
時間をかけて（テストやレビューを増やす等）品質を改善するアプローチしかとれないという傾向です。
ビジネスやユーザにとっての品質をリードせず、内向きの品質のみを扱う
ユーザの要求を満たしたり、ビジネスに成功したりするのに必要な品質を見出して、その実現のために開発をリードするアプローチを取らないという傾向です。代わりに、プロセス定義の合致性や、開発部門が検出した不具合の解消、インシデント対応といった、品質要求の変化の影響を受けない妥当性確認・検証に閉じこもります。
実務書には、こうすべきだという著者の主張には賛同できなくとも、読み進むうちに、著者がその考えに至った背景、状況、問題認識がぐっと迫ってくる本がある。一方で、主張だけが宙に浮いていて、著者がどんな状況と格闘してきたのかさっぱり見えない本もある。たぶん、格闘してないんだろう。
ハードル上げてきたな。
この御仁の美しくないところは「自分が一番優れている」と言い切るのではなく、他者を貶めることで自分の価値を持ち上げようとする卑屈な虚栄心にある。
技術者としてはともかく人間性に関しては...であるな。
マイクロサービスの苦労話を聞くほど、APIファーストじゃなくて必要なのはDBファーストだよなって思う。トランザクションでどこまでのデータを一緒に扱いたいか、データの更新頻度とか。裏のデータベースにある内容を後から取り出したいと追加するのは簡単。後から境界を跨ぐのは困難。
データベースを隠すべき実装詳細と見るのか、アプリケーションから見た時の外部システムと見るのか、という視点の違いだと思う。
まあヘキサゴナルアーキテクチャも永続化のレイヤーは外にいるので「APIファースト」と言いつつDBファースト設計するのは両立する。
本を書きました。設計本ですが、設計のプロセスや手法ではなく、どんな基幹系システムを実現できればステキと思うかという点に重点をおいた本です。
プロセスや手法は、もういいんです。必要でないということはありませんが、過剰です。
入門書ではありませんが、あまり予備知識なく読めるよう工夫したので、みなさん、是非お読みください。
基幹系システム、それに「設計する」ということに対するイメージを変えて頂けるのではないかと思います。
本書のテーマは「データモデリング」と「基幹系システム」です。
Web上で台頭しつつある新たなビジネスは、新たな基幹系システムを必要としています。一方、既成ビジネスでは、モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。
基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン、つまりデータモデリングがいずれの取り組みにおいてもカギですが、データモデリングが真価を発揮するには、その知識体系を現代的に仕立て直す必要があります。
本書では、「活動のシステム」と「経営管理のシステム」という線引きを導入し、2つの領域で異なる帳簿特性を踏まえて、分散／非同期／疎結合な基幹系システムのための実践的データモデルを詳説します。さらには、データモデル理論の基礎にも新たな光をあてて、論理削除、テーブル分割、履歴管理といった共通論点に解決の糸口を提供し、支持を得ているドメイン駆動設計との関係性を探究します。
どの言語を使ってるとかで侮る風潮未だに残ってる気がするんですが、もうそろそろやめません？というのが最近の気持ちです。
Insomnia は、オープンソースの API クライアントです。API 通信を GUI で直感的に検証・保存できる、というのが最も基本的な機能です。似たようなツールだと Postman などが有名だと思います。
Insomnia は一般的な REST API だけでなく、GraphQL や gRPC の API にも対応したツールです。JX通信社では、NewsDigest や FASTALERT などのサービスで GraphQL を活用しているため、GraphQL にネイティブ対応しているのは非常に便利です。
過去にブログシステムを自作したときは「Webで食っていくならブログぐらいは自作してあるべき」と考えていたらしいです。そんな感じのことは今もほんのり思いつつも、実際に自作するとなると作るべき機能が山ほどある（参考: The Surprisingly High Table Stakes of Modern Blogs）わけだし、無理にしょぼいサイトを作るぐらいならば素直にはてなブログを使ったほうが良いだろうな、という気持ちです。はてなブログは機能が超充実していて普通にすごい。
と言いつつも、自分のサイトの一部としてブログをホストしていること自体が記事を書くモチベーションにつながっていたりして、人間の感情は複雑だなぁと思っています。
アプリ自体は先述した通りRails製で、何かをすごく工夫している点はないです（強いて言えばルーティングぐらい）。デプロイはVPS上にHashicorp Nomadを使ってやっていて、こちらも何かしら特別な仕掛けがあるわけでもなし。Nomadは何もしなくてもすてきなコンソールがついてきてよい。
半導体業界の変化の年
上述したような半導体業界の動き、という意味では、2024年にはさらに異なる視点の変化もあります。
今年はIntelの新世代CPUであるMeteor Lake（そしてその後継となるArrow Lake）や、AMDのZen 5のような、10～20パーセント近い大きな性能ジャンプが生じるプロセッサの登場が予定されています。もちろんあまりにも大きなジャンプは「既存の製品が売れなくなる」という結果をもたらすため、ある程度は「手加減された」変化になる可能性はあるものの、この10年ほどの「CPUのクロック周波数やクロックあたりの性能はそこまで伸びない、マルチコアによって性能を伸ばす」という展開とは異質な変化が起きる年であると言えるでしょう。
さらに、いわゆるx64 CPUだけでなく、ArmとRISC-VベースのCPUも大きく性能を伸ばしてきています。Windows 10の終焉と併せて、ここから2-3年の間は業界地図が大きく変化していくことになるでしょう。また、vRANブーストのような「特定目的向けCPU」というものも広がっていくことになります。
Pagefind は、静的サイト向けの全文検索エンジンと UI ライブラリです。Cloud CMS を提供している CloudCannon 社により開発されています。
特定のフレームワークに依存しない JavaScript ライブラリとして実装されており、静的サイトジェネレーターで生成された HTML ファイルに対して検索機能を追加できます。追加するコードの量も少なく、簡単に検索機能を実装できます。
興味深い
クリーンアーキテクチャのことで「DBを入れ替えることが無い」という話がよくあるけど、モバイルアプリだと無料でローカル、有料でリモートのデータストアを利用することがあるよね。
それはサービスのバックエンドの部分ではDBを入れ替えることは現実的に考えにくいという話で、アプリ側ではそういうニーズがあるんです！ というなら、それならそれを考慮して設計しましょうという話にしかならないのだ。
要するに思考停止してはいかんというだけの話である。
ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。
- テクノロジーマネジメント
- アーキテクチャやテストなど
- プロジェクトマネジメント
- 見積もりやアジャイル開発など
- プロダクトマネジメント
- ビジョンや仮説検証など
- ピープルマネジメント
- メンバーの成長やメンタリングなど