スタートアップでも、マイクロサービスには多くの利点があると思います。まず、モノレポを使う利点は本当におすすめです。

• プロダクトの方向性が修正されたとき、マイクロサービスはモノリシックよりも修正すべき箇所が明確で少ないです。私はこれが本当に大きいと思います。
• AI開発の時代において、マイクロサービスの小さな単位はAIを使って開発しやすいです。（モノリシックではできないという意味ではありません）
• CI/CDの負担は認めますが、方向性を固める段階で整理されるサービスもあります。最終的に方向性が固まった段階で構築しても、ほぼコピペレベルなので1週間以内に構築可能です。
• 言語ごとに強みのあるオープンソースは明確です。SecurityとビジネスロジックはJavaで、AIはPythonで、という形で、マイクロサービス構成ではできるだけ多くのオープンソースを活用できます。

1と0でできた世界から離れては一日たりとも生きられなくなってしまったのでしょうか……。他人事とは思えませんね……。

範囲を絞ることをスコーピングといいます。勝てるようにうまくスコーピングすることが能力なのです。

デジタルデトックスは聞いたことがありますが、デジタルボトックスは初めて聞きましたねｗｗｗｗ
具体的にStarlinkがどのように動作するのか気になっていたのですが、疑問がかなり解消されました。

この記事で言及されている電波保護帯域は 1400-1427 MHz で、ここにはこの記事で述べられている土壌や海洋の観測だけでなく、電波天文学で観測される銀河の水素ガスからの電波（1420.405 MHz）も含まれています。
そのため、軍事衝突で発生する強力な電子的ジャミングは、電波天文学を非常に困難にするといいます。

参考までに、この記事で言及されている衛星データを使って、毎月単位でこの帯域で捕捉された電波干渉を地図上に表示して見せるウェブページがあります。

• SMAP Maps: Radiometer RFI

これを見ると、非常に特異なのが日本列島です。ほかの地域は、主に軍事的緊張がある場所でなければ散発的な点として表示されているのに、日本列島だけは島全体が真っ赤に表示されていました。しかも、上記ウェブページが表示する最も古いデータは 2015年4月のデータですが、その時点ですでに全国土が真っ赤に染まっていました。

そこで、なぜ日本だけあのような状態なのかを調べてみると、原因は日本で普及したデジタル衛星放送受信機だそうです。
日本では 2011年7月にアナログTV放送を終了し、同年12月に BSデジタル衛星放送チャンネルを24チャンネルに増やしたといいます。この衛星放送信号は 12 GHz という高い周波数なので、機器でそのまま処理するのは負担が大きく、内部的に IF（中間周波数）へ変換して処理するそうです。
問題は、21チャンネルの場合、中間変換周波数が 1415-1450 MHz となり、上で述べた電波保護帯域と重なってしまう点で、当時の日本の関連規格は今より緩かったようです。
結果として、その帯域で電波が少しずつ漏れる受信機や分配増幅器が数百万台、日本全国に分布することになり、これによって問題が発生しました。個々の機器から漏れる干渉電波の量は基準値以内でしたが、これらが同時に数百万台単位で動作することで、その帯域自体が影響を受けるようになったのです。
2018年以降、日本の総務省が衛星放送受信機の製造・設置規格を強化し、既存受信機の交換に補助金を出しているものの、この問題は現在まで解決されないまま残っています。

日本関連の内容の出典:

• SMOS RFI EXPERIENCE IN THE 1400-1427MHz PASSIVE BAND DUE TO RADIATIONS AT INTERMEDIATE FREQUENCY OF SATELLITE HOME-TV RECEIVERS

わあ… Starlinkは名前だけ聞いたことがありましたが、実際の使用レビューを見ると不思議ですね。楽しく読ませていただきました！

OpenSearch は、Elasticsearch のライセンス変更を受けて 2021 年に登場し、互換性のある代替を目指していました。特に 1.x は Elasticsearch 7.10 とおおむね互換性がありますが、完全なドロップインソリューションではありません。Elasticsearch はその後さらに進化し、より多くの機能や最適化を備えており、特に Kibana と集計機能でその傾向が顕著です。パフォーマンスはアプリケーション依存で、どちらも Lucene 上に構築されています。一部のユーザーは OpenSearch のほうが遅く、Kibana のフォークに不具合があると感じています。2024 年 9 月に Elasticsearch がオープンソース（AGPLv3）へ回帰したにもかかわらず、その真にオープンソースな性質と AWS のサポートを理由に OpenSearch を好む人もいます。ベクトル検索は主要な差別化要因ですが、大規模な実装には慎重な RAM 管理が必要です。最終的には選択は具体的なニーズ次第であり、どちらにも長所と短所があります。私は Davidayo とともに OpenSearch に取り組んでいます https://www.davidayo.com AI の強力なツール "AskPromptAI" https://askpromptai.com.

意見欄でも少し出ていましたが、beam/otp 系はこういうかなり柔軟で良い感じですね。Gleam の場合は、go と rust 両方の良い文法に beam の安定性が加わって、かなり印象的な言語になっています。小規模プロジェクトでそろそろ使ってみたいですね。

WA!(SM)

チームをやたらと細かく分けると、集まって意見を交わすことさえ非常に大きな業務になってしまいます。

Astro : JavaScriptを最小限に配信する
Astro 3.0 リリース

同じ種同士のコミュニケーションというのは、群れで生活しないなら交尾のときにしか使われないのでは、という気もしますが、不思議ですね。

エンジンもまともに作れない会社が、くだらないことばかりやってるんですね（笑）

+1
Next.jsを少しかじっただけかも（笑）

なるほど、もっともな気がしますね（笑）

アニメーションはどれも良いのですが、内容よりもアニメーションにばかり目が行ってしまうページが多すぎるんですよね。

特にアニメーションのせいで読む流れまで邪魔されると、読み始める前からイライラしてしまいます。

本当に印象的な内容でした！
実務ですぐに適用できるヒントも多いですね。共有ありがとうございます ☺️

The One-Person Framework 実践適用記
1人の女性開発チームで200万人のユーザーを達成する
上の2つの記事もRailsがあったからこそ可能だったという話で、最近はRailsの話題が増えてきているようですね。

Ruby on Railsが今なお重要な理由 - Next.jsの世界で古いツールが生き残る方法
Next.jsを離れてRuby on RailsとInertia.jsに戻った理由
Rails for Everything - すべてのためのRailsの強さ

勝利宣言ができるような仕事を選ぶことも、重要なスキルのようです。

うちの会社では、cursor など最近出てきた AI エディタは導入せず、VS Code に Continue extension をインストールして使う程度でしか LLM を使っていないのですが。あと 2〜3 年くらいして支配的なコードエディタが出てきたら、そのとき導入してみようかなとは思っています……