Coded Chords - Software

読了『闘うプログラマー』

2026-05-12T07:33:12+09:00

Table of Contents</summary> </details>

1980年代にMS-DOSでデスクトップパソコン市場を制し、WindowsでGUIのオペレーティング・システム(以降、「OS」と記載)も制しつつあったマイクロソフト社は、90年代、高性能コンピューター向けの「本物」のOS開発プロジェクトを立ち上げます。当時のマイクロソフト社の世界戦略を担ったOS「WindowsNT」です。そのプロジェクトに、当時DEC社のミニコン向けOS、VAX/VMSの開発者であった「伝説のプログラマー」David Neil Cutlerが招へいされました。

本書の概要</h2>
本書は、David Cutlerを中心とした開発物語です。
『闘うプログラマー』というタイトルから、David Cutler中心に描かれていると思って購入しました。冒頭は、彼がDEC社で担当していた新OSプロジェクト「Mica」が破棄され、1988年マイクロソフト社に移籍するシーンから描かれています。前半は彼がいかにWindowsNTプロジェクトを立ち上げたかが描かれていますが、中盤からはこのプロジェクトに参加したあらゆるレイヤーの開発者へと順次フォーカスが当てられ、エピソードが盛り込まれていきます。
全く新しいOSを、当時主流だったIntelのCPUだけでなく、まだ完成していないRISCにも対応させなければなりません。さらにDOSとの互換性、Win32系の旧来のWindowsとの互換性も維持する必要があったわけです。想像するだけでデスマーチな開発ですが、本書を読めば実際にデスマーチだったことが分かります。それでも当時は「Cutlerの元で新しいOSの開発が出来る」ことを栄誉だと考えるプログラマーが多くいたわけです。
Cutlerの伝記として読むと中途半端ですが、当時のWindowsNTの過酷な開発エピソードが盛り込まれている点は大変興味深く読めました。本書がWindowsNTの初版がリリースされた1993年に出版されたため、開発者たちのエピソードも生々しく、リアルな状況を伝えています。

「OSの時代」を背景に</h2>
WindowsNTの開発が始まった1980年代後半から1990年代に掛けては、まさに「OSの時代」でした。当時は、ハードウェアやネットワークの環境が大きく変化した時代でもあります。

CPUは16ビットから32ビットに進化し、RISCという新しいアーキテクチャーも登場した</li>
MacintoshがGUIを一般ユーザーに広めた結果、プリエンプティブなマルチタスクが一般レベルでも要求されるようになった</li>
インターネットの普及により、モデムでのパソコン通信ではなく本格的なネットワーク機能が一般ユーザーでも必要となった</li> </ul>
PCはMS-DOS上でWindows3.xが動いていましたが、16ビットアーキテクチャーを引きずっていました。IBMは「OS/2」という新しいOSをマイクロソフト社と共にリリースしていましたが、コンシューマーの世界では全く浸透していませんでした。Apple社はClassic Mac OSを何度も刷新しようとしていましたが、ことごとく失敗していました。
そんな中で開発されたWindowsNTは、その後Windows2000、WindowsXPとコンシューマー向けWindowsの核となり、最も成功したOSとなっていきました。
私自身、1995年頃に自宅のPCにWindowsNTを導入していました。とはいえ、当時実際に使っていたツールの大半はWindowsベースですらなく、DOSベースのものが中心だったように記憶しています。それでも「本物のOS」に触れられたこと自体はよいお勉強になりましたし、ファイルシステムのNTFSはFATに比べて信頼性が明らかに高く、家庭利用でもその差を実感できました。
米国でのプログラマーの地位</h2>
個人的に印象的だったのは、米国での「プログラマー」の地位です。WindowsNTの開発に参加していた開発者が、皆スタープログラマーという訳ではありませんでした。それでも多くの開発者はストックオプションで一財産を築き、西海岸に家を建てポルシェを購入してという経済的な成功を手に入れています。日本における「プログラマー」の扱いとは大違いです。
翻って日本では、多くのプログラマーがSIer (システムインテグレーター) を頂点とする多重下請け構造の中で受託開発に従事しています。給与水準は一般のサラリーマンと大きく変わらず、ストックオプションで一財産を築くケースは稀です。「35歳定年説」も語られるほどに、プログラマーを続けること自体、報われにくい構造でした。
この差の背景には、産業構造の違いが大きいのではないでしょうか。米国はマイクロソフト社のように自社プロダクトを開発・販売する事業会社が産業の主役で、その成功は株式を通じて開発者個人にも還元されます。一方、日本では事業会社がIT機能を外注する構造になっており、プロダクトの成功を開発者と分け合う仕組みもありません。経営層に技術者出身者が少ないことも、こうした地位の差を生む一因と感じます。
</a></div>
闘うプログラマー新装版</a>
posted with ヨメレバ</a></div></div>
グレッグ・パスカル・ザカリー/山岡洋一日経BP 2009年07月 </div>
楽天ブックス</a></div>
Amazon</a></div>
Kindle</a></div> </div></div>
</div></div>

GoFデザインパターンは現代でも有用か(4) — 現代でも有用なパターンとまとめ

2026-04-06T08:06:00+09:00

Table of Contents</summary> </details>

前回までの振り返り</h2>

第1回</a>では、OOPのパラダイムシフトとGoFデザインパターンの誕生、そしてGo言語による脱OOPの流れを振り返りました。

第2回</a>では、Go言語の3つの設計方針がGoFの23パターンのうち10パターンを不要にしたことを検証しました。

第3回</a>では、残る13パターンのうち、言語機能として取り込まれたIteratorと、現代の設計手法により非推奨となったSingletonを検討しました。

分類</th> パターン</th> 状態</th></tr></thead>

OOPの制約への処方箋（第2回）</td> Template Method, Factory Method, Abstract Factory, Bridge, Prototype, Memento, Strategy, Command, Visitor, Observer</td> 不要</td></tr>

言語機能として吸収（第3回）</td> Iterator</td> 意識不要</td></tr>

設計手法の進化で非推奨（第3回）</td>

Singleton</td>

非推奨</td></tr> </tbody></table>

本記事では、残る11のパターンがなぜ現代でも有用なのかを分析し、シリーズ全体の結論としてデザインパターンの本質的価値を考察します。

現代でも有用なパターン</h2>
残る11のパターンは、継承と参照セマンティクスのいずれにも依存していません。ここまで見てきたパターンがOOPの言語メカニズムへの処方箋だったのに対し、これらはOOPとは無関係に存在する、ソフトウェア設計の普遍的な課題を解決するものです。つまり、GoFの23パターンの中にはOOPの処方箋と、言語に依存しない設計の原則「ソフトウェアアーキテクチャの原則」が混在していたのです。
生き残ったパターンを、その理由ごとに分類します。

小さな部品を合成して大きな振る舞いを作る</h3>

Go言語の設計思想「継承より合成（composition over inheritance）」と直結する分類です。小さな部品を組み合わせて複雑な構造や振る舞いを構築するという原則は、プログラミングパラダイムを問わず有効です。

Builder — 複雑なオブジェクトを段階的に構築する。Go言語ではfunctional optionsパターンとして定着している</li> </ul> コンポーネント間の境界を制御する</h3> ソフトウェアの規模が大きくなると、コンポーネント間の依存関係やインターフェースの不一致が複雑さの主要因になります。この問題に対処するパターンは、言語やパラダイムに関係なく必要です。 Adapter — 互換性のないインターフェース同士を橋渡しする。外部ライブラリやレガシーシステムとの統合で常に必要になる</li> Facade — 複雑なサブシステムに対して統一的な窓口を提供する。Go言語ではパッケージの公開APIを絞ることで自然に実現される</li> Proxy — 対象へのアクセスを制御する代理を提供する。遅延初期化、アクセス制御、ログ記録など用途が幅広い</li> Mediator — 多対多のオブジェクト間の相互作用を仲介者に集約し、疎結合にする。イベントバスやメッセージブローカーの設計に通じる</li> </ul> 状態に応じて振る舞いを切り替える</h3> State — 内部状態に応じてオブジェクトの振る舞いを変更する。Go言語ではStateインターフェースを定義し、状態ごとに異なる型で実装する。有限状態マシンの設計に直結する</li> </ul> 特定領域の問題を解決する</h3> Flyweight — 多数の細粒度オブジェクトの共有によりメモリ使用量を削減する。文字列のインターン化やキャッシュなど、メモリ最適化が必要な場面で有効</li> Interpreter — 言語の文法を定義し解釈する。DSL（ドメイン固有言語）や設定ファイルのパーサー、式評価エンジンなど、特定の用途で使われる</li> </ul> まとめ — デザインパターンの本質的価値とは何だったのか</h2> GoFの功績は、コード内で繰り返し現れるパターンに名前を付け、開発者の共通言語を確立したことにあります。「ここはObserverで」「Adapterを挟もう」と言えば設計意図が伝わる。この語彙の確立は、ソフトウェア開発の生産性に大きく貢献しました。 しかし、本記事の分析が示すように、GoFの23パターンには性質の異なる2種類のものが混在していました。 実装の工夫 : パラダイムシフトを起こしたばかりのOOPの未成熟さをカバーするもの。継承の副作用を管理するTemplate MethodやVisitor、参照セマンティクスを補完するPrototypeやMemento。これらはOOPという特定のパラダイムの制約の中で必要だった処方箋であり、パラダイムが変われば不要になるもの。</li> 普遍的な設計原則 - 合成による構築、境界の制御など設計のベストプラクティス。CompositeやDecorator、AdapterやFacadeは、OOPとは無関係に、ソフトウェアの複雑さに対処するためのアーキテクチャの知恵。</li> </ul> GoFの問題は、この2つがあまり区別されず、同列にカタログ化されたことです。そして当時、OOPが成熟した段階を経験したプログラマが少なかったことも相まって、GoFは必要以上に神格化されました。本来はコードレベルの実装パターンであるにもかかわらず、当時は業務システムのアーキテクチャを語る場面でGoFのパターン名が持ち出されるような頓珍漢なエンジニアさえ出現しました。デザインパターンは「設計パターン」と訳されますが、実態は「コードパターン」であったことに留意すべきです。 Go言語が示したのは、OOPの制約に起因するパターンは言語設計で解消できるということです。そして残った11のパターンこそが、GoFの本質的な遺産「言語やパラダイムを超えた設計原則」だったと言えます。 ただし、この結論すら永続的なものではありません。Rustの列挙型とパターンマッチングはStateパターンを言語機能として吸収しつつありますし、名前付き引数やデフォルト値を持つ言語ではBuilderの必要性が薄れます。今日「普遍的な設計原則」に見えるものも、将来の言語やパラダイムの進化によって、さらに整理されていく可能性があります。 デザインパターンの本質的な価値は、23のカタログそのものにはありませんでした。ソフトウェアの複雑さに名前を付け、共有可能な知識として体系化しようとした試み「その営み」こそが、GoFの真の貢献だったのではないでしょうか。 本シリーズで取り上げたGoFの23パターンすべてをGo言語で実装したサンプルコードを公開しています。 </iframe> GoFデザインパターンは現代でも有用か(3) — 言語に吸収されたパターンと非推奨のSingleton 2026-04-02T10:15:00+09:00 Table of Contents</summary> </details> 前回までの振り返り</h2> 第1回</a>では、手続き型プログラミングからOOPへのパラダイムシフト、その中でGoFデザインパターンが「OOPでよいコードを書くためのお手本」として体系化された経緯を振り返りました。そして現代では、OOPの中核 — クラス継承、型階層、参照セマンティクス — を意図的に排除したGo言語が登場し、新たなパラダイムシフトが起きていることを確認しました。 第2回</a>では、Go言語の3つの設計方針がGoFの23パターンのうち10パターンを不要にしたことを検証しました。 Go言語の設計方針</th> 不要になったパターン</th></tr></thead> クラス継承を排除し、合成と暗黙的インターフェースで代替</td> Template Method, Factory Method, Abstract Factory, Bridge</td></tr> 参照セマンティクスではなく値セマンティクスをデフォルトに</td> Prototype, Memento</td></tr> 振る舞いもオブジェクトに包む制約を廃し、第一級関数とチャネル/ゴルーチンで直接扱えるように</td> Strategy, Command, Visitor, Observer</td></tr> </tbody></table> これらはOOPの制約の中で生まれた処方箋であり、制約そのものを取り除いたGo言語では必要なくなったものでした。では、残る13パターンはどうでしょうか。本記事では、言語機能として取り込まれたものと、設計手法の進化で非推奨となったものを検討します。 言語機能として取り込まれたパターン</h2> デザインパターンの中には、その有用性が広く認められた結果、現代の言語では標準的な機能として取り込まれたものがあります。デザインパターンが語られた当時はOOPがまだ成熟しておらず、これらの機能をユーザーで実装していたとも言えます。これらのパターンは「不要になった」のではなく、「わざわざパターンとして意識する必要がなくなった」と言えます。 Go言語も例外でなく、言語仕様としてこれらのパターンを取り込んでいます。 コレクションの内部構造を公開せずに要素を走査する</h3> Iterator — イテレータオブジェクトを別途定義し、hasNext()</code>/next()</code>のようなインターフェースを実装する必要があった</li> </ul> 『Java言語で学ぶデザインパターン入門</a>第3版』(結城浩著)1</a>のIteratorパターンのサンプルコードを見てみます。本棚（BookShelf）に本（Book）を格納し、イテレータで順に取り出すという例です。 public class Book { private String name; public Book(String name) { this.name = name; } public String getName() { return name; } }</code></pre>import java.util.Iterator; public class BookShelf implements Iterable<Book> { private Book[] books; private int last = 0; public BookShelf(int maxsize) { this.books = new Book[maxsize]; } public Book getBookAt(int index) { return books[index]; } public void appendBook(Book book) { this.books[last] = book; last++; } public int getLength() { return last; } @Override public Iterator<Book> iterator() { return new BookShelfIterator(this); } }</code></pre>import java.util.Iterator; import java.util.NoSuchElementException; public class BookShelfIterator implements Iterator<Book> { private BookShelf bookShelf; private int index; public BookShelfIterator(BookShelf bookShelf) { this.bookShelf = bookShelf; this.index = 0; } @Override public boolean hasNext() { if (index < bookShelf.getLength()) { return true; } else { return false; } } @Override public Book next() { if (!hasNext()) { throw new NoSuchElementException(); } Book book = bookShelf.getBookAt(index); index++; return book; } }</code></pre>import java.util.Iterator; public class Main { public static void main(String[] args) { BookShelf bookShelf = new BookShelf(4); bookShelf.appendBook(new Book("Around the World in 80 Days")); bookShelf.appendBook(new Book("Bible")); bookShelf.appendBook(new Book("Cinderella")); bookShelf.appendBook(new Book("Daddy-Long-Legs")); // 明示的にIteratorを使う方法 Iterator<Book> it = bookShelf.iterator(); while (it.hasNext()) { Book book = it.next(); System.out.println(book.getName()); } System.out.println(); // 拡張for文を使う方法 for (Book book: bookShelf) { System.out.println(book.getName()); } System.out.println(); } }</code></pre> 上記Javaコードは結城浩氏によるサンプルコード（MIT License</a>、Copyright (c) 2001,2004,2021 結城浩 / Hiroshi Yuki）です。 4つのファイル、約80行のコードが必要です。BookShelfIterator</code>クラスが走査の状態（現在のインデックス）を管理し、hasNext()</code>とnext()</code>のインターフェースを実装しています。BookShelf</code>はIterable<Book></code>を実装し、iterator()</code>メソッドでイテレータを生成します。 Go言語で同じBookShelfを書くとどうなるでしょうか。Go 1.23で導入されたrange-over-function（iter.Seq</code>）を使うと、Javaと同等のカスタムコレクションを以下のように実装できます。 package main import ( "fmt" "iter" ) type Book struct { Name string } type BookShelf struct { books []Book } func (s *BookShelf) Append(book Book) { s.books = append(s.books, book) } func (s *BookShelf) All() iter.Seq[Book] { return func(yield func(Book) bool) { for _, book := range s.books { if !yield(book) { return } } } } func main() { shelf := &BookShelf{} shelf.Append(Book{Name: "Around the World in 80 Days"}) shelf.Append(Book{Name: "Bible"}) shelf.Append(Book{Name: "Cinderella"}) shelf.Append(Book{Name: "Daddy-Long-Legs"}) for book := range shelf.All() { fmt.Println(book.Name) } }</code></pre> JavaではIterable</code>インターフェース、Iterator</code>実装クラス、hasNext()</code>/next()</code>メソッドの3層が必要でした。Go言語ではiter.Seq</code>型の関数を1つ返すだけで済みます。イテレータの状態管理（インデックスの保持、終端判定）はクロージャが担い、専用のクラスを書く必要がありません。 現代の設計手法により非推奨となったパターン</h2> インスタンスが1つだけであることを保証する</h3> Singleton — クラスのインスタンスが1つだけであることを保証し、グローバルなアクセス手段を提供する</li> </ul> 典型的な例として、アプリケーションの設定情報（Config）をSingletonで管理するケースを見てみます。Go言語で実装した例です。 var ( instance *Config once sync.Once ) type Config struct { DBHost string DBPort int } func GetConfig() *Config { once.Do(func() { port, _ := strconv.Atoi(os.Getenv("DB_PORT")) instance = &Config{ DBHost: os.Getenv("DB_HOST"), DBPort: port, } }) return instance } type UserRepository struct{} func (r *UserRepository) FindByID(id int) (*User, error) { // どこからでもGetConfig()でアクセスできる config := GetConfig() dsn := fmt.Sprintf("%s:%d/mydb", config.DBHost, config.DBPort) // ... }</code></pre> Configのようなオブジェクトは、システムにインスタンスを1つだけ持つのが都合よいものです。そのため、このような実装が広く行われていました。しかし、テストのシーンを考えると、このパターンは問題があります。 UserRepository</code>はConfig</code>に依存していますが、その依存は関数の引数に現れません。テスト時に本番と異なる設定を注入することも困難です。 Singletonは、OOPの副作用とは無関係に、現代の多くの設計指針で非推奨とされるパターンです。問題の本質は「インスタンスが1つ」であることではなく、「グローバルなアクセス手段を提供する」という点にあります。GetConfig()</code>のようなグローバル関数を通じてどこからでもアクセスできることが、隠れた依存関係を生み、テスト時のモック差し替えを困難にします。 注意すべきは、「ライフサイクルとしてのシングルトン」まで否定しているわけではないことです。DIコンテナがオブジェクトのスコープをシングルトンとして管理すること（SpringのデフォルトスコープやGoのfxにおけるライフサイクル管理など）は、依存関係が明示的である限り問題ありません。非推奨なのは、GoFが定義した「グローバルアクセスを提供するパターンとしてのSingleton」です。 現代では、依存性の注入（Dependency Injection）がこの問題に対するより優れた解法として確立されています。必要な依存を明示的に引数として渡すことで、グローバル状態を排除し、テスト容易性と可読性を確保します。同じ設計をDIで書くと次のようになります。 type Config struct { DBHost string DBPort int } type UserRepository struct { config Config } func NewUserRepository(config Config) *UserRepository { return &UserRepository{config: config} } func (r *UserRepository) FindByID(id int) (*User, error) { dsn := fmt.Sprintf("%s:%d/mydb", r.config.DBHost, r.config.DBPort) // ... } func main() { config := Config{ DBHost: os.Getenv("DB_HOST"), DBPort: 3306, } repo := NewUserRepository(config) // ... }</code></pre> UserRepository</code>が何に依存しているかがNewUserRepository</code>の引数として明示されています。テスト時には異なるConfig</code>を渡すだけで済みます。 まとめ</h2> 本記事では、GoFの残り13パターンのうち2つを検討しました。 Iterator — 言語機能として吸収され、パターンとして意識する必要がなくなった</li> Singleton — OOPの副作用とは無関係に、グローバル状態という本質的な問題から非推奨となった。依存性の注入（DI）がより優れた解法として確立されている</li> </ul> 次回は、残る11のパターンがなぜ現代でも有用なのかを分析し、シリーズ全体の結論としてデザインパターンの本質的価値を考察します。 このリンクはAmazonアソシエイトのリンクです。 ↩</a> </li> </ol> </section> GoFデザインパターンは現代でも有用か(2) — Go言語で不要になったパターン 2026-04-01T10:00:00+09:00 Table of Contents</summary> </details> 前回の振り返り</h2> 前回</a>は、OOPが手続き型プログラミングからのパラダイムシフトとして登場した経緯、OOPの設計ノウハウを体系化したGoFデザインパターンが広く受け入れられた歴史、そして現代ではOOPの中核を意図的に排除したGo言語が登場したことを振り返りました。 Go言語の設計方針は、OOPとの対比で次の3点に集約されます。 クラス継承を排除し、合成（composition）と暗黙的インターフェースで代替した</li> 参照セマンティクスではなく値セマンティクスをデフォルトにした</li> 振る舞いもオブジェクトに包む制約を廃し、第一級関数とチャネル/ゴルーチンで直接扱えるようにした</li> </ul> この設計方針を踏まえて、GoFの23パターンをGo言語の視点から再検討してみましょう。 「クラス継承」の副作用への処方箋だったパターン</h2> OOP「クラス継承」がもたらしたもの</h3> ソフトウェアの保守性と拡張性を担保するために、「既存のコードを変更せずに機能を拡張する」という原則 — 開放閉鎖原則（Open-Closed Principle）が求められてきました。手続き型言語では、機能を追加するたび既存コードへ分岐を追加するしかなく、変更が既存の動作を壊すリスクが常にありました。OOPはこの課題に対して、クラス継承という新たなメカニズムで解決を図りました。基底クラスを定義し、サブクラスで振る舞いをオーバーライドすることで、既存コードに手を加えずに機能を拡張します。これがOOPの基本戦略でした。 しかし、継承自体が新たな問題を生みます。 脆弱な基底クラス問題 — 親クラスを変更すると、全てのサブクラスに影響が波及する。「変更せずに拡張」したかったのに、親を変えた瞬間に子が壊れる</li> 密結合 — サブクラスは親クラスの実装詳細に依存する。拡張のつもりが、内部実装への依存を生む</li> 単一継承の制約 — Java等では1つのクラスしか継承できない。拡張の方向が1軸に制限される</li> 深い階層の可読性低下 — 継承が何段にも重なると、実際の振る舞いを追うのが困難になる</li> </ul> デザインパターンは、この継承の副作用を管理するための処方箋でした。以下のパターンが該当します。 Template Method — 親クラスでアルゴリズムの骨格を定義し、サブクラスで具体的なステップをオーバーライドする。継承による骨格と詳細の分離を体系化したもの</li> Factory Method — オブジェクトの生成をサブクラスに委ねることで、生成ロジックの拡張を継承で管理する</li> Abstract Factory — 関連するオブジェクト群の生成を抽象クラスの階層で管理する</li> Bridge — 抽象クラスの階層と実装クラスの階層を分離し、それぞれ独立して拡張可能にする。継承階層を2つに分けることで拡張の柔軟性を確保する</li> </ul> これらはいずれも「継承をどう使えば安全に拡張できるか」を体系化したものであり、継承というメカニズムが前提にあって初めて意味を持つパターンです。 Go言語の解法 — 継承のない拡張性</h3> Go言語はこの問題の連鎖に対して、根本的に異なる道を選びました。クラス継承を排除し、暗黙的インターフェースと合成（composition） によって開放閉鎖原則を実現しています。 暗黙的インターフェース — implements</code>の宣言が不要で、メソッドのシグネチャが合致すれば自動的にインターフェースを満たす。既存の型に触れることなく、新しいインターフェースへ適合させられる。つまり、既存コードを変更せず新しい抽象に対応できる</li> 合成（composition） — 構造体の埋め込み（embedding）により、既存の型を変更せずに振る舞いを追加できる。継承のような親子の密結合が生まれず、拡張しても既存コードへの影響がない</li> </ul> 継承の副作用が存在しないため、その副作用を管理するためのデザインパターンも必要ありません。これらのパターンが「Go言語では成立しない」のは、解決すべき問題が言語設計の時点で回避されているからです。 「参照セマンティクス」を補完するパターン</h2> 「参照セマンティクス」がもたらしたもの</h3> OOPの多くの言語は参照セマンティクス^{1</a>を採用しています。これはOOPの設計思想と深く結びついています。OOPでは「このオブジェクトとあのオブジェクトは同一か」というオブジェクトの同一性（identity）が重要であり、基底クラスの参照を通じて派生クラスのメソッドを呼び出すポリモーフィズムも参照なしでは成立しません。参照セマンティクスはOOPにとって必然的な選択でした。} しかし、参照セマンティクスは副作用も伴います。変数に代入してもオブジェクト自体はコピーされず、同じ実体を指す参照が増えるだけです。C言語でいえば、すべての変数がポインタ経由でデータにアクセスしているようなものであり、手続き型言語のグローバル変数と同様に「どこで変更されるか追跡できない」という課題をオブジェクト単位で持ち込んでしまいます。この性質がオブジェクトの複製や状態の保存・復元を厄介な問題にし、それを解決するためのデザインパターンが必要でした。 Go言語は値セマンティクス2</a>を採用しています。OOPを捨てたことで、参照をデフォルトにする必要がなくなりました。値セマンティクスは並行処理の安全性（ゴルーチン間でコピーを渡せば共有状態が減る）と予測可能性（代入の振る舞いが明示的で単純）をもたらします。参照が必要な場合は、ポインタで明示的に指定します。 この「デフォルトは値、参照が必要なら明示せよ」という設計方針は、Go言語独自のものではありません。Rustはムーブセマンティクスをデフォルトとし参照は&</code>で明示します。Swiftは構造体（struct）を値型とし、Appleは構造体の使用を推奨しています。OOP以降の現代的な言語設計に共通するトレンドです。 この値セマンティクスにより、以下のパターンが解決しようとした問題は大幅に簡素化されます。 既存オブジェクトをコピーして新しいオブジェクトを生成する</h3> Prototype — 参照セマンティクスの世界では、オブジェクトの「正しいコピー」を作ること自体が設計上の課題であり、Clone()メソッドの実装やプロトタイプ登録といった仕組みが必要だった</li> </ul> Go言語では、構造体の代入がそのままコピーです。b := a</code>と書けばフィールドがすべて複製されます。ポインタを含む構造体の深いコピーには注意が必要ですが、パターンとしての仕組みは不要です。 オブジェクトの内部状態を保存し復元する</h3> Memento — Originator（状態を持つ対象）、Memento（保存された状態）、Caretaker（保存を管理する者）の3者構造で、カプセル化を壊さずに状態を保存・復元する仕組みを実現していた</li> </ul> Go言語では、構造体をそのままコピーすればスナップショットになります。saved := currentState</code>で保存、currentState = saved</code>で復元です。OOPが苦心した「カプセル化を維持しつつ状態を外部に保存する」という問題自体が、値セマンティクスによって解消されています。 「振る舞い」をオブジェクトに包む制約への処方箋だったパターン</h2> 「すべてがオブジェクト」がもたらしたもの</h3> OOPの「すべてがオブジェクト」という原則は、データと振る舞いを一体化することで、手続き型言語のようにデータと関数がバラバラに散らばる問題を解消しました。統一的なモデルで設計を語れることは、OOPの大きな功績です。 しかし、ソフトウェアでは要件の変化や文脈の違いに応じて、データはそのままに処理だけを差し替える場面が頻繁に発生します。同じデータを異なる基準でソートしたい、同じリクエスト処理を本番ではDB接続、テストではモックに差し替えたい、といった場面です。OOPの「すべてがオブジェクト」という原則は、このような振る舞いだけを渡したい場面でも、それをオブジェクト（クラス）に包むことを強制しました。関数を1つ渡したいだけなのに、インターフェースを定義し、具象クラスを実装し、そのインスタンスを生成する。この儀式が、以下のパターンを生みました。 Go言語では、第一級関数であり、チャネルとゴルーチンが言語に組み込まれています。振る舞いをオブジェクトに包む必要がなくなったことで、これらのパターンは不要になりました。 アルゴリズムを動的に切り替える</h3> Strategy — Strategyインターフェースを定義し、各アルゴリズムを具象クラスとして実装し、コンテキストオブジェクトに注入するという手順が必要だった</li> </ul> Javaでは、ソート順を差し替えるだけでもインターフェースと具象クラスが必要です。 // Strategyインターフェース interface SortStrategy { void sort(int[] data); } // 具象クラス：昇順 class AscendingSort implements SortStrategy { public void sort(int[] data) { /* 昇順ソート */ } } // 具象クラス：降順 class DescendingSort implements SortStrategy { public void sort(int[] data) { /* 降順ソート */ } } // コンテキストクラス class Sorter { private SortStrategy strategy; Sorter(SortStrategy strategy) { this.strategy = strategy; } void execute(int[] data) { strategy.sort(data); } } // 使用側 Sorter s = new Sorter(new AscendingSort()); s.execute(data);</code></pre> Go言語では第一級関数をサポートしています。ソート処理を行う関数が、ソート順を関数として受け取るだけで済みます。 // ソート順を関数として受け取る。クラスもインターフェースも不要 func executeSort(data []int, less func(i, j int) bool) { sort.Slice(data, less) } // 関数を変数に代入するだけで「具象クラス」に相当する ascending := func(i, j int) bool { return data[i] < data[j] } descending := func(i, j int) bool { return data[i] > data[j] } // 使用側 executeSort(data, ascending)</code></pre> Javaでは振る舞いを差し替えるためにインターフェース、具象クラス、コンテキストクラスの3層が必要でした。Go言語では関数を引数として渡すだけで同じことが実現できます。 操作の実行・取り消し・キューイングを可能にする</h3> Command — リクエストをオブジェクトとしてカプセル化し、操作をデータとして扱えるようにしていた</li> </ul> Go言語では関数とクロージャがCommandオブジェクトの役割を果たします。関数をスライスに格納してキューイングする、クロージャで実行時のコンテキストを閉じ込める、といった操作が言語機能として自然に書けます。 データ構造に新しい操作を追加する</h3> Visitor — データ構造に対する操作を追加したいとき、操作をVisitorオブジェクトに包み、ダブルディスパッチ（accept/visit）で呼び出す必要があった</li> </ul> Go言語ではtype switchにより、型に応じた処理分岐を直接記述できます。操作をオブジェクトに包む必要も、ダブルディスパッチのような間接的な仕組みも不要です。 オブジェクトの状態変化を通知する</h3> Observer — Subject/Observerインターフェースを定義し、登録・通知・解除のメカニズムを実装する必要があった</li> </ul> エラーイベントが発生したら、ログ出力とアラート送信の2つの処理に通知する例で対比してみます。 Javaでは、Observerインターフェースの定義、Subject（EventSource）への登録メカニズム、通知ループの実装が必要です。 // Observerインターフェース interface Observer { void update(String event); } // 具象クラス：ログ出力 class LogObserver implements Observer { public void update(String event) { System.out.println("Logger: " + event); } } // 具象クラス：アラート送信 class AlertObserver implements Observer { public void update(String event) { sendAlert(event); } } // Subject：Observerの登録と通知を管理する class EventSource { private List<Observer> observers = new ArrayList<>(); void addObserver(Observer o) { observers.add(o); } void notifyObservers(String event) { for (Observer o : observers) { o.update(event); } } } // 使用側：Observerを登録し、イベントを通知する EventSource source = new EventSource(); source.addObserver(new LogObserver()); source.addObserver(new AlertObserver()); source.notifyObservers("error occurred");</code></pre> Go言語では、チャネルとゴルーチンがこの役割を担います。Observerをチャネルのスライスで管理し、動的に登録できます。 // チャネル：Observerへの通知経路をスライスで管理 observers := []chan string{} // Observer登録：チャネルを作成し、ゴルーチンで待ち受ける logCh := make(chan string) observers = append(observers, logCh) go func() { for event := range logCh { fmt.Println("Logger:", event) } }() alertCh := make(chan string) observers = append(observers, alertCh) go func() { for event := range alertCh { sendAlert(event) } }() // 全Observerに通知 for _, ch := range observers { ch <- "error occurred" }</code></pre> Javaではインターフェース定義、登録メカニズム、通知ループが必要でした。Go言語ではチャネルが型安全な通知メカニズムとなり、ゴルーチンが通知を受け取る側の並行処理を自然に表現します。 まとめ</h2> 本記事では、Go言語の3つの設計方針がGoFのデザインパターンをどのように不要にしたかを確認しました。 Go言語の設計方針</th> 不要になったパターン</th></tr></thead> クラス継承を排除し、合成と暗黙的インターフェースで代替</td> Template Method, Factory Method, Abstract Factory, Bridge</td></tr> 参照セマンティクスではなく値セマンティクスをデフォルトに</td> Prototype, Memento</td></tr> 振る舞いもオブジェクトに包む制約を廃し、第一級関数とチャネル/ゴルーチンで直接扱えるように</td> Strategy, Command, Visitor, Observer</td></tr> </tbody></table> これらのパターンが不要になったのは、パターンの設計思想が間違っていたからではありません。OOPの制約の中で生まれた処方箋が、制約そのものを取り除いたGo言語では必要なくなった、ということです。 しかし、GoFの23パターンすべてがOOPの制約に起因するわけではありません。次回は、言語やパラダイムに依存しない普遍的な設計原則として、現代でも有用なパターンを検討します。 参照セマンティクス（reference semantics）とは、変数への代入がオブジェクトの参照（ポインタ）をコピーする振る舞いのこと。代入先を変更すると、元のオブジェクトも影響を受ける。Java、Pythonなどが採用している（C#はクラスが参照型、構造体が値型と区別している）。 ↩</a> </li> 値セマンティクス（value semantics）とは、変数への代入がデータそのものをコピーする振る舞いのこと。代入先を変更しても、元のデータには影響しない。Go言語の構造体やC言語の構造体が採用している。 ↩</a> </li> </ol> </section> GoFデザインパターンは現代でも有用か(1) — OOPのパラダイムシフトとGoFの誕生 2026-04-01T05:58:00+09:00 Table of Contents</summary> </details> 自宅の本棚の整理をしていて、『Java言語で学ぶデザインパターン入門</a>第2版』(結城浩著)1</a>を見つけました。「今どきJava言語かね」と思い調べてみると、5年程前に第3版が出版されていました。 「そう言えば、今どきの言語でデザインパターンってどうなんだ？」と考察していました。 本記事では、なぜ脱オブジェクト指向プログラミング（以降、OOP）のパラダイムシフトが起きたのか、そしてGoFの23のデザインパターンをGo言語ではどう扱うべきかを検討し考察してみます。 手続き型プログラミングの限界</h2> 1960年代から1980年代にかけて、ソフトウェア開発の主流は手続き型プログラミングでした。C言語やFortranに代表されるこのパラダイムでは、データと手続き（関数）は分離して管理されます。プログラムの規模が小さいうちは問題になりませんが、規模が大きくなるにつれて、どの関数がどのデータを操作するのかを追跡することが困難になっていきました。 当時仕事ではメインフレーム中心で私の職場ではPL/Iを使っていましたが、規模を大きくしないためかバッチ指向のデザインが好まれていました。そのため1つ1つは短いプログラムですが、内部ではグローバル変数への依存、関数間の暗黙的なデータ受け渡しが行われていました。そして短いプログラムでも、結局ファイルを介してバッチストリーム全体がストレージ共有をしているので、変更の影響範囲が予測できないという問題が深刻化しました。 やがて、1990年代に入るとWindows/Macintoshに加えて、IBMのOS/2、SunやHPのワークステーションが業務で使えるレベルのシステムとなり、「ダウンサイジング」の波が業務アプリケーションの世界にも押し寄せました。この問題はさらに致命的になりました。 OOPというパラダイムシフト</h2> OOP（オブジェクト指向プログラミング）は、手続き型プログラミングにおけるデータと手続きの分離がもたらす複雑さに対するパラダイムシフトでした。データとそれを操作する手続きを「オブジェクト」として一体化し、カプセル化によって内部状態を保護する。オブジェクト間はメッセージパッシングで協調し、継承によってコードを再利用する。Simula（1967年）で芽生え、Smalltalk（1980年）で確立されたこの思想は、1990年代にC++やJavaの普及とともに主流となりました。 OOPの普及を決定づけたのは、ダウンサイジングがもたらしたGUIクライアントの台頭です。Windowsの普及により、ソフトウェアはウィンドウ、ボタン、メニューといった視覚的な部品で構成されるようになりました。これらのUI部品は、状態を持ち、イベントに応答し、階層的に組み合わされる — まさにオブジェクトとしてモデル化するのに適した対象でした。GUIツールキットはOOPの実践的な成功例となり、OOPこそがソフトウェア開発の正しいアプローチであるという認識を広めました。 一方でOOPは、カプセル化、継承、ポリモーフィズムという新しい概念を持ち込んだために、手続き型言語で機能分割しかやって来なかった当時の開発者たちに「OOPではどうコードを書くべきなのか」と悩ませることになりました。 GoFデザインパターンの誕生</h2> この状況の中で、1994年にGoF（Gang of Four）2</a>が『Design Patterns: Elements of Reusable Object-Oriented Software』を出版しました。GoFはオブジェクト指向設計で繰り返し現れる23のパターンを、生成（Creational）5種、構造（Structural）7種、振舞（Behavioral）11種の3つに分類して体系化しました。これらのパターンは、当時の開発者にとって「OOPでよいコードを書くためのお手本」として受け入れられました。 分類</th> パターン名</th> 概要</th></tr></thead> Creational（生成）</td> Abstract Factory</td> オブジェクトを具象クラスを指定せずに生成</td></tr> </td> Builder</td> 複雑なオブジェクトを抽象化し段階的に生成</td></tr> </td> Factory Method</td> オブジェクトの生成をサブクラスに委ねる</td></tr> </td> Prototype</td> 既存オブジェクトをコピーし新オブジェクトを生成</td></tr> </td> Singleton</td> インスタンスが1つだけであることを保証</td></tr> Structural（構造）</td> Adapter</td> 互換性のないインターフェースのクラス同士を接続</td></tr> </td> Bridge</td> 抽象部分と実装部分を分離。独立に変更可能</td></tr> </td> Composite</td> ツリー構造により個別オブジェクトと合成を同一視</td></tr> </td> Decorator</td> オブジェクトに動的に新しい責務を追加</td></tr> </td> Facade</td> サブシステムの複雑なインターフェースの統一的な窓口</td></tr> </td> Flyweight</td> 多数の細粒度オブジェクトを共有してメモリ使用量削減</td></tr> </td> Proxy</td> 他のオブジェクトへのアクセス制御する代理オブジェクト</td></tr> Behavioral（振舞）</td> Chain of Responsibility</td> リクエスト処理するオブジェクト連鎖を構成し処理を委譲</td></tr> </td> Command</td> リクエストをオブジェクト化し、実行取消や再実行を可能</td></tr> </td> Interpreter</td> 言語の文法を定義し解釈するインタプリタを提供</td></tr> </td> Iterator</td> 内部構造を公開せずに、集合要素へアクセスする方法</td></tr> </td> Mediator</td> オブジェクト間の相互作用を仲介者に集約し疎結合</td></tr> </td> Memento</td> オブジェクトの内部状態を保存し、復元可能に</td></tr> </td> Observer</td> 状態変化を他のオブジェクトに自動的に通知</td></tr> </td> State</td> オブジェクトの内部状態に応じて振舞を変更する</td></tr> </td> Strategy</td> アルゴリズムをカプセル化し、実行時に切り替え可能</td></tr> </td> Template Method</td> アルゴリズムの骨格を定義、ステップをサブクラスに委譲</td></tr> </td> Visitor</td> データ構造と処理を分離し、新しい処理を追加しやすくする</td></tr> </tbody></table> 新たなパラダイムシフト — なぜGoogleはOOPを捨てたのか</h2> GoFが出版されてから10年以上が経った2007年、Googleの中で新しい言語の設計が始まりました^{3</a>。} 新言語の開発に踏み切った背景には、GoogleのC++コードベースの深刻な問題がありました。数百万行規模のコードではビルドに数十分から数時間を要し、複雑な依存関係の管理は開発者の大きな負担になっていました。C++の持つ豊富な機能 — テンプレート、多重継承、演算子オーバーロード — は、大規模なチーム開発においてコードの可読性を損ない、新しいメンバーの参入障壁を高めていました。 Go言語の設計者たちが出した答えは、複雑さを足すのではなく引くことでした。2009年にオープンソースとして公開されたGo言語は、OOPの中核を意図的に排除し、代わりに以下の設計方針を採用しています。 クラス継承を排除し、合成（composition）と暗黙的インターフェースで代替した</li> 参照セマンティクスではなく値セマンティクスをデフォルトにした4</a></li> 振る舞いもオブジェクトに包む制約を廃し、第一級関数とチャネル/ゴルーチンで直接扱えるようにした</li> </ul> 確かに近年はC++/JavaのようなOOPでなく、次のような言語を選択するシーンが私自身も増えています。 Python — クラスも書けるが、関数だけでも十分に実用的</li> Ruby — 実は言語設計は徹底的にOOP（全てがオブジェクト）。ただし実際の使われ方は柔軟</li> JavaScript — そもそもクラスベースではなくプロトタイプベース。ES6のclassは後付けの構文糖</li> TypeScript — JavaScriptに型を足したもの。OOPと関数型のどちらでも自然に書ける</li> </ul> これらはOOPですがマルチパラダイムで、OOPじゃないパラダイムでもコードが書けます。 では、Go言語はOOPなのでしょうか。Go言語にはメソッドやインターフェースがあり、カプセル化も実現できます。しかし、クラスや継承はありません。Go言語のFAQでは「Yes and no」と回答されています。Go言語はOOPの有用な部分（カプセル化、多態性）を残しつつ、複雑さの元凶（継承、型階層）を切り捨てた言語です。上記のような言語からさらにOOPを薄めたものと言えます。 Go言語の登場は、OOPに続く新たなパラダイムシフトの象徴です。 ここで1つの疑問が浮かびます。GoFのデザインパターンは「OOPでよいコードを書くためのお手本」として受け入れられました。しかし、Go言語はそのOOPの中核 — 継承、型階層、参照セマンティクス — を排除しています。もしGoFのパターンが本当にOOPの仕組みに依存したものであるなら、Go言語ではそれらのパターンは成立しないはずです。逆に、パターンの中に言語やパラダイムに依存しない普遍的な設計原則が含まれているなら、Go言語でも形を変えて生き残るはずです。 次回は、GoFの23のパターンをGo言語の視点から1つずつ再検討し、この仮説を検証していきます。 このリンクはAmazonアソシエイトのリンクです。 ↩</a> </li> Gang of Four（GoF）は、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissidesの4人の通称。 ↩</a> </li> 主導したのはRob Pike（UNIXやPlan 9の開発者）、Ken Thompson（UNIXの共同開発者）、Robert Griesemerの3人です。 ↩</a> </li> 参照セマンティクス（reference semantics）とは、変数への代入がオブジェクトの参照（ポインタ）をコピーする振る舞いのこと。値セマンティクス（value semantics）とは、変数への代入がデータそのものをコピーする振る舞いのこと。 ↩</a> </li> </ol> </section> Mac環境のリフレッシュ 2026-03-17T15:34:11+09:00 Table of Contents</summary> </details> 見送っていたMac環境のリフレッシュを実施しました。 MacPaw関連ソフトウェアの見直し</h2> MacPaw1</a>の次の2つのソフトウェアを使用していました。 CleanMyMac X: macOSのメンテナンス・ユーティリティ</li> Gemini 2: 重複ファイル削除ツール</li> </ul> いずれもサブスクリプションが中心ですが、私は2022年にロシアのウクライナ侵攻が起こった際に支援のつもりでLifeTimeの買い切りで購入しています。コストも発生せず、どちらも便利なツールです。 しかし、常駐して僅かですがリソースを食っているのが気になっていました。今回はどちらもアンインストールして、CLI代替ツールに移行しました。 Mole — macOSクリーンアップツール</h2> </iframe> macOSのクリーンナップと最適化に特化したコマンドラインツールです。 CleanMyMac、AppCleaner、DaisyDisk、iStat Menusなどの機能を1コマンドでカバーしていると謳っています。 mo clean # キャッシュ・ログ・ブラウザ残骸の削除 mo uninstall # アプリの完全アンインストール mo optimize # キャッシュ再構築・サービスリフレッシュ mo analyze # ディスク使用量の可視化 mo status # CPU/GPU/メモリ/ディスク/ネットワークのリアルタイム監視 mo purge # 開発プロジェクトのビルド成果物削除 mo installer # Downloads内の.dmg/.pkgの整理</code></pre> 結構危険な処理をするツールですが、いずれも--dry-run</code>オプションがサポートされており、実際に削除する前に検証できます。 実際、CleanMyMac Xで使用していた機能のうちマルウェアスキャン以外はほぼカバーされています。マルウェアスキャンについては、macOS標準のXProtectとGatekeeperがかなり優秀なので、基本的に追加のスキャナは不要と判断しました。 Czkawka（チカフカ） — 不要ファイル検出ツール</h2> </iframe> 主に重複ファイルの削除に使用していたGemini 2の代替です。名前はポーランド語で「しゃっくり」を意味します。 rmlint</a>も検討しましたが、rmlintはバイト単位での重複判定のみで、Gemini 2のように画像の類似性による重複判定には対応していません。 その点Czkawkaは、パーセプチュアルハッシュによる類似画像検出をサポートしています。GUI版もありますが、安定のCLI版を使っています。 # 重複ファイル検出: -d 検索先 -e 除外先 -m 最小25B -s hash比較 -D aeo(最古以外を削除) czkawka_cli dup -d ~/Documents -e ~/Documents/Archive -m 25 -x 7z rar IMAGE -s hash -f results.txt -D aeo # 空フォルダ検出: 複数ディレクトリ指定可 czkawka_cli empty-folders -d ~/Documents ~/Downloads -f results.txt # 巨大ファイル検出: -n 上位25件 -x VIDEO拡張子を除外 czkawka_cli big -d ~/Documents -e ~/Documents/Archive -n 25 -x VIDEO -f results.txt # 類似画像検出: パーセプチュアルハッシュで視覚的に似た画像を検出 czkawka_cli image -d ~/Pictures -e ~/Pictures/Wallpapers -f results.txt # 壊れたシンボリックリンク検出 czkawka_cli symlinks -d ~/Projects -e ~/Projects/.git -x jpg -f results.txt # 破損ファイル検出: ヘッダが壊れたファイル等を検出 czkawka_cli broken -d ~/Downloads -f results.txt</code></pre> 重複ファイル、類似画像、空ファイル・フォルダ、一時ファイル、破損ファイル、拡張子不一致、不正ファイル名など、Gemini 2以上に多彩な検出機能を備えています。 なお、SenseiとCocktailは引き続き使用しています。Senseiはハードウェア情報やSSDのTrim管理に、CocktailはmacOSの定期メンテナンスタスクの自動実行に、それぞれ役割が明確なので残しました。 メニューバーの整理</h2> MacBookでメニューバーにたくさんアイコンが並ぶと、ノッチの裏に隠れて見えなくなる問題があります。この対策としてメニュー表示管理ツールを使用していました。 Bartenderから数年前にIce</a>へ移行しましたが、macOS Tahoeではメニュー構造が変わった影響で動作が不安定になっていました。 代替として次のようなツールがありますが、いずれも新しいmacOSのメニュー構造の変更に対応しきれていないようでした。 Hidden Bar</li> Bartender 5（有料）</li> Vanilla</li> iBar</li> </ul> しかし、macOS Tahoeではメニューバーのカスタマイズ機能が大幅に強化されました。「システム設定 > メニューバー > メニューバーの操作」から、次の操作が可能になっています。 アプリごとにメニューバーへの表示のオン・オフを制御</li> Apple純正機能はコントロールセンターへ移動可能</li> Command+ドラッグでアイコンの並び替え</li> </ul> サードパーティ製ツールのように表示の動的な切り替えやレイアウト変更には対応していませんが、常駐アイコンの大半を整理できました。もうサードパーティ製ツールは不要です。 ブラウザArcの代替</h2> 数年前に彗星のごとく登場したArcを愛用していましたが、2025年5月にThe Browser Companyが開発終了を発表しました。理由は「ほとんどの人にとってArcは違いが大きすぎて学習コストに見合わなかった」という"novelty tax"問題とのことです。後継としてAIブラウザ「Dia」の開発に注力するとされていますが、Arc自体はセキュリティ修正のみのメンテナンスモードに入っています。 当初はGoogle Chrome + Side Space拡張機能でほぼArcと同等のことができるかと試していました。しかし、Arcの全機能を再現しようとすると拡張の組み合わせが増えるばかりで、本末転倒だと気づきました。 結局、Safariに落ち着いています。iCloudとの連携、省電力性能、macOS標準のパスキー対応など、Apple製品で統一している環境であれば素直にSafariが最適という結論です。 まとめ</h2> GUIの常駐アプリをCLIに置き換え、メニューバーをOS標準機能で整理し、ブラウザもSafariに一本化しました。 やっとメニューバーが整理でき、mo clean</code>一発でMacのクリーンナップもできる。そういう小さな快適さの積み重ねで、深呼吸できた心地がします。ゴミの山は鼻をつまんで走り抜けるに限ります。 References</h2> GitHub - tw93/mole</a>. "Mole - Deep clean and optimize your Mac"</li> GitHub - qarmin/czkawka</a>. "Multi functional app to find duplicates, empty folders, similar images etc."</li> Sensei — Cindori</a>. 「Mac Performance Monitor & Cleaner」</li> Cocktail — Maintain</a>. 「A perfect mixture for macOS」</li> Apple Support</a>. "Change Menu Bar settings on Mac"</li> Engadget</a>. "The Browser Company stops active development of Arc in favor of new AI-focused product"</li> </ul> </div> Macのユーティリティ系ソフトウェアを開発・販売しているウクライナのベンダー ↩</a> </li> </ol> </section> gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール 2026-03-07T22:00:00+09:00 Table of Contents</summary> </details> （2026-06-04更新） 本記事は当初、Gyroflowスタンドアロンアプリ向けの5つのパラメータを推奨する内容でした。その後、実運用のワークフローがDaVinci Resolve上のGyroflow OpenFXプラグインで完結することを踏まえ、推奨対象をプラグイン版「Adjust parameters」に一本化しました。以下では旧スタンドアロンアプリ版の記述に取り消し線を引き、新しい内容を併記しています。 </blockquote> Gyroflowのパラメータ調整は面倒である</h2> DJI NeoやAvataシリーズでFPV撮影をしている方なら、Gyroflowでの後処理は日常的な作業だと思います。EISをオフにして撮影し、Gyroflowでスタビライズする。この流れ自体は確立されていますが、問題はGyroflowのパラメータ調整です。 Gyroflowには主に5つの調整パラメータがあります。</del> DaVinci ResolveなどでGyroflow OpenFXプラグインを使う場合、調整の中心になるのは「Adjust parameters」パネルのSmoothnessとZoom limitです。スタンドアロンアプリ版にあった細かなパラメータはプラグインのUIには現れず、.gyroflow</code> プロジェクト側に焼き込まれます（2026-06-04更新）。 パラメータ</th> 意味</th></tr></thead> Smoothness (1〜300)</td> スムージングの強度。高いほどブレを強く除去するが、意図した動きも鈍る</td></tr> Max smoothness (s)</del></td> 突発的なブレに対する最大補正量</del>（プラグイン版では非対応）</td></tr> Max smoothness at high velocity (s)</del></td> 高速旋回時の補正上限。短くすると旋回への追従性が上がる</del>（プラグイン版では非対応）</td></tr> Zoom limit (%)</td> 安定化で生じる黒縁を隠すためのズーム上限</td></tr> Zooming speed (s)</del></td> Dynamic zoomingのFOV遷移速度</del>（プラグイン版では非対応）</td></tr> FOV</td> 画角。算出対象外でベースライン1.0を提示</td></tr> </tbody></table> プラグインのSmoothnessは1〜300のスケール（デフォルト50）で、gyrotriageが従来出力していた百分率の値をそのまま入力できます。強く設定すればブレは消えますが、意図したカメラワークまで平滑化されたり、クロップで解像度が落ちたりします。適切な値はクリップごとに異なるため、毎回プレビューを見ながら試行錯誤することになります。 1本2本ならまだしも、フライト後に何十本ものクリップを処理するときは正直つらい作業です。 gyrotriageでパラメータ推定を自動化する</h2> </iframe> そこで作ったのが gyrotriage です。DJIドローンのMP4ファイルを渡すだけで、埋め込まれたモーションデータを解析し、ブレの度合いをスコアリングしつつ、Gyroflowの5つのパラメータ</del>Gyroflow OpenFXプラグイン（DaVinci Resolve等）に入力するパラメータを自動で推定します。 考え方はシンプルです。パイロットが意図したカメラワーク（パン・チルト・旋回）と除去したいブレ（風や機体振動）では、動きの周波数帯域が異なります。ゆっくりしたパンは1Hz以下の低周波、プロペラ振動は20Hz以上の高周波に現れます。この境界を信号処理で自動検出し、Gyroflowの内部ロジックに合わせてパラメータに変換しています。 インストール</h2> macOSの場合はHomebrewでインストールできます。 brew install gyrotriage</code></pre> Rustの開発環境がある場合はcargoからもインストールできます。 cargo install --path .</code></pre>使い方</h2> 基本的な使い方はMP4ファイルを渡すだけです。 gyrotriage DJI_0001.MP4</code></pre> 以下のようなテキスト出力が得られます。 File: DJI_20260228080801_0003_D.MP4 Duration: 30.3s (60593 samples @ 2000Hz) Score: 100 / 100 Level: SEVERE RMS: 34.8 °/s Peak: 644.0 °/s Pitch: avg=1.4°/s std=2.2°/s max=47.9°/s Roll: avg=11.7°/s std=13.5°/s max=251.1°/s Yaw: avg=3.3°/s std=4.4°/s max=89.0°/s --- Gyroflow plugin (Adjust parameters): Smoothness: 21 Zoom limit: 118 FOV: 1.000 Integration method: None Lens correction: 100</code></pre> 末尾の「Gyroflow plugin (Adjust parameters)」ブロックが、Gyroflow OpenFXプラグインの「Adjust parameters」パネルにそのまま入力できる推奨値です。最後の2行がGyroflowに入力する推定パラメータです。</del> このうちSmoothnessとZoom limitはモーション解析から算出した値、Integration methodとLens correctionはDJI機の特性に基づく固定推奨です。この値をプラグインのパネルに入力すれば、そこから微調整を始められます（2026-06-04更新）。 なお旧スタンドアロンアプリ版では、末尾の出力が Gyroflow: smoothness=21% max=0.300s max@hv=0.030s zoom_limit=118% zooming_speed=2.6s</code></del> という5値の形式でした。 HUD表示で直感的にブレを把握する</h2> --visual</code> オプションを付けると、ブレの特性をHUD風のグラフィックで表示します。 gyrotriage DJI_0001.MP4 --visual</code></pre> 冒頭のカバー画像がHUD出力の実例です。画面には以下の情報が表示されます。 スコアゲージ: ブレの重大度を0〜100で表示（STABLE / MILD / MODERATE / SEVEREの4段階）</li> レーダーチャート: Pitch・Roll・Yawの3軸でブレの偏りを可視化</li> ライングラフ: 合成角速度と各軸の角速度の時系列変化</li> 推定パラメータ: Gyroflowに入力する5つの値</del>Gyroflow OpenFXプラグインに入力する推奨値</li> </ul> 数値だけでは分かりにくい「このクリップはRoll方向のブレが支配的」「後半に激しいブレが集中している」といった特性が一目で把握できます。Gyroflowプラグインを適用する前に、どのクリップにどの程度の処理が必要かをトリアージするのに役立ちます。 HUD画像はPNGファイルとしても出力できます。 gyrotriage DJI_0001.MP4 --output-image shake.png</code></pre> WezTermやiTerm2などSixel/iTerm2プロトコルに対応したターミナルでは --visual</code> でインライン表示されます。非対応のターミナルでは --output-image</code> でファイル出力してください。 テキストのみの環境向けには --sparkline</code> オプションもあります。 gyrotriage DJI_0001.MP4 --sparkline</code></pre>スコアの読み方</h2> gyrotriageはブレの重大度を0〜100のスコアで表示します。 レベル</th> スコア</th> 目安</th></tr></thead> STABLE</td> 0〜25</td> ブレはほぼなし。スタビライズ不要</td></tr> MILD</td> 26〜50</td> 軽微なブレ。スタビライズは任意</td></tr> MODERATE</td> 51〜75</td> 目に見えるブレ。Gyroflow推奨</td></tr> SEVERE</td> 76〜100</td> 激しいブレ。Gyroflow必須</td></tr> </tbody></table> DJI Air 3Sのような3軸ジンバル搭載機ではほぼSTABLEになりますが、DJI Neoのような1軸ジンバル機やAvataシリーズでアクロバティックな飛行をした場合はMODERATE〜SEVEREになることが多いです。 推定パラメータの使い方</h2> ~~出力された5つのパラメータはGyroflowのUIに直接入力できます。~~出力された推奨値はGyroflow OpenFXプラグインの「Adjust parameters」パネルに直接入力できます（2026-06-04更新）。 Gyroflowでクリップを開く</del>DaVinci ResolveのタイムラインでクリップにGyroflowプラグインを適用する</li> 出力された値をそれぞれのスライダーに入力する</li> プレビューで確認し、必要に応じて微調整する</li> </ol> このとき、Integration methodはNone、Lens correctionは100、FOVは1.0を起点にします。DJI機はクォータニオンを記録済みなので再積分が不要で、正しいレンズプロファイルを読み込めばフル補正で問題ないためです。 推定値はあくまで調整の出発点です。ブレが残っている場合はSmoothnessを上げる、カメラワークが鈍く感じる場合はSmoothnessを下げる、といった微調整で仕上げてください。ゼロからスライダーを動かして探るよりも、妥当な出発点があるだけで調整時間は大幅に短縮できます。 対応機体と撮影条件</h2> モーションデータがMP4へ埋め込まれるDJI機種に対応しています。ただし撮影時の設定次第ではモーションデータが記録されないため、注意が必要です。 機体</th> 条件</th></tr></thead> DJI Avata / Avata 2</td> EIS（Rocksteady）オフ、FOV Wide</td></tr> DJI Neo / Neo2</td> アスペクト比4:3（EISは自動的にオフ）</td></tr> </tbody></table> Avataシリーズの場合、Rocksteadyをオンにしているとモーションデータが記録されません。Gyroflowで後処理する前提なら、撮影時はRocksteadyオフ・FOV Wideで撮影してください。 DJI Neoの場合、16:9で撮影するとモーションデータが記録されません。4:3で撮影する必要があります。 DJI Air 3Sなど3軸ジンバル搭載機はGyroflow自体を必要としないケースが多く、対象外としています。 実際の効果</h2> gyrotriageで推定したパラメータを微調整なしでそのままGyroflow OpenFXプラグインに適用した映像（右）と、オリジナルの未処理映像（左）の比較です。 </iframe> </div> 注意事項</h2> 推定値は信号処理に基づく客観的な算出であり、映像の主観的な品質評価は含まない</li> 非常にゆっくりしたブレ（0.3Hz未満）は意図した動きと区別できない</li> GyroflowのDefaultアルゴリズムを前提としており、Plain 3Dや軸別モードでは推定値の解釈が異なる</li> 極端に短いクリップ（2秒未満）では推定精度が低下する</li> 商用空撮など業務用途では、必ずGyroflowのプレビューで結果を検証すること</li> </ul> Gyroflow</a>. 「Gyroflow - Video stabilization using gyroscope data」</li> </ul> </div> 5つのクラシックUADプラグイン：黄金時代のスタジオレジェンド 2026-01-11T00:00:00+00:00 I took advantage of Universal Audio's sale to build my mastering-focused plugin collection. Here's a deep dive into the 5 legendary plugins I picked up. These include the Pultec EQP-1A, LA-2A, and Lexicon 224. I also got the SSL G Bus Compressor and Ampex ATR-102. I'll cover their fascinating history from The Beatles to 1980s pop. You'll also learn exactly how to use each one in Logic Pro on individual tracks, buses, or the master channel for professional results. The Plugins I Purchased</h2> Pultec EQP-1A</h3> Developed by Pulse Techniques in 1951, the EQP-1A has been cherished for over 70 years as the most musical passive equalizer. Its unique design combining tube amplification with passive components prevents phase distortion even when boosting or cutting, creating a beautiful harmonic enhancement effect. The famous "low-end trick" of simultaneously boosting and cutting the low frequencies is widely known as a technique for adding both punch and clarity to kicks and bass. It has been used across generations, from The Beatles to modern hip-hop. In Logic Pro, the Pultec EQP-1A is extremely versatile and can be used at multiple stages of production. As an Audio FX insert on individual tracks, it excels at shaping kick drums and bass guitars with the famous "low-end trick," adding clarity while maintaining weight. On vocal tracks, gentle high-frequency boosts add air and presence without harshness. The EQP-1A is also highly effective on instrument buses (such as drum buses or vocal buses), adding cohesive tonal shaping across grouped elements. Additionally, many mastering engineers use it on the final master track to add subtle sweetness and harmonic richness to the entire mix. The UAD plugin collection includes the HLF-3C for high frequencies and MEQ-5 for midrange, extending the Pultec family's sonic palette across the frequency spectrum. </div> LA-2A Tube Compressor</h3> Released by Teletronix in 1965, the LA-2A is a legendary compressor combining tube amplification with a T4 optical element. Its unique operation with automatically adjusted attack and release times achieves extremely natural and musical compression for vocals, bass, and guitar. Particularly for vocal processing, it has been beloved for nearly 60 years as "smooth and transparent compression," used on countless classic albums from Motown to modern pop. Despite its simple operation, the sound quality it delivers is irreplaceable. In Logic Pro, the LA-2A excels primarily as an Audio FX insert on individual tracks. The most common application is on lead vocals, gently controlling dynamics while maintaining presence and clarity. It's also highly effective on bass guitar tracks, adding sustain and consistency without making the tone sound over-compressed. For acoustic guitars and electric guitar solos, the LA-2A provides a musical cohesion that naturally blends the performance into the mix. Some engineers use it on a vocal bus for group processing when handling background vocals or vocal stacks, applying gentle glue compression across multiple vocal tracks. Unlike mix bus compressors, the LA-2A is rarely used on the master track. Its characteristics are best showcased when applied to specific sources rather than the entire mix. </div> Lexicon 224 Digital Reverb</h3> Introduced in 1978, the Lexicon 224 revolutionized music production as the world's first commercial digital reverb. It achieved precisely controlled spatial representation that was impossible with previous plate or spring reverbs. This created the rich and expansive reverb that characterized 1980s pop, rock, and fusion sounds. The "sparkling and three-dimensional reverberation" when used on drums and vocals became an iconic sound of that era. In Logic Pro, the Lexicon 224 is most effectively used as a send effect on an Aux track. Create an Aux channel and insert the Lexicon 224 as an Audio FX. Then use send controls to route multiple tracks (vocals, drums, guitars) to this reverb bus. This approach allows independent blending of wet reverb signal and dry source signal for each track. It enables precise control of spatial depth and placement. The most common applications include drum overheads and room mics for creating classic 1980s drum ambience. Lead and background vocals benefit from added depth and dimension. Guitar solos and synth pads can create vast soundscapes. Using reverb on an Aux track (rather than as an insert) also conserves CPU resources. Multiple tracks can share the same reverb instance. Some engineers use the Lexicon 224 on dedicated reverb buses for specific instruments (such as "Drum Reverb" or "Vocal Reverb"). This enables different reverb settings for different sonic elements in the mix. </div> SSL G Bus Compressor</h3> In the 1980s, the master bus compressor installed in the SSL 4000 G Series console established a legendary status. It became known as equipment that imparts a "glue" effect to the entire mix. Despite its modest ratio settings, it excels at integrating the entire mix into a cohesive single sound image. It's particularly powerful in rock, pop, and dance music. The effect of creating punch and cohesion simply by inserting it on the stereo bus is called "SSL Glue" and has become an indispensable technique in modern mixing. In Logic Pro, the SSL G Bus Compressor is primarily used on the Stereo Out (master track). As its name suggests, it's inserted as one of the final processors in the master chain, bringing the entire mix together. Typically used with gentle settings (2:1 or 4:1 ratio, slow attack, auto release) to achieve 1-3 dB of gain reduction. Many engineers insert this early in the mixing process, "mixing into the compressor," allowing the compressor to shape mixing decisions from the start. The SSL G Bus Compressor is also effective on submix buses. On drum buses, it can add punch and cohesion when kick, snare, and other drum elements work together. It's also commonly used on instrument group buses (all guitars, all synths, background vocals) to create a more unified sound within each section. Unlike individual track compressors like the LA-2A, the SSL G Bus Compressor reveals its true value in processing multiple elements simultaneously. It's not suitable for application to single tracks. </div> Ampex ATR-102 Mastering Tape Recorder</h3> Introduced in the late 1970s, the Ampex ATR-102 is known as the pinnacle of 2-track mastering tape recorders. Through its unique sonic characteristics of tape saturation, tape compression, and high-frequency roll-off, it adds warmth and depth lacking in digital recordings. Many engineers have passed tracks through this equipment in the final mastering stage, imparting cohesion and a "glue-like" effect to the entire work. The UAD emulation also allows selection of tape speed (15/30 ips) and tape type. In Logic Pro, the Ampex ATR-102 is almost exclusively used on the Stereo Out (master track), placed as the final processor in the signal chain or very close to it. Insert it after the mix bus compressor and EQ, before the final limiter or metering plugin. Tape emulation provides subtle analog saturation and gentle compression effects. As a result, it helps the mix feel more cohesive and "finished." Typical settings include 15 ips for warmer, more saturated characteristics emphasizing low-end bloom, or 30 ips for cleaner, more transparent tape sound achieving tight low-frequency response. The choice of tape formulation (GP9, 456, 900) further shapes tonal character and saturation behavior. Some mixing engineers use the ATR-102 on submix buses (such as drum buses or instrument buses), adding analog character to specific elements before they reach the master fader. However, its primary purpose is processing in the final mastering stage, providing the "analog finish" typical of digital production. Summary</h2> These five Universal Audio plugins represent different eras of studio technology, but when used together they form a comprehensive toolkit for modern music production. Understanding where each plugin fits in the signal flow is key to using them effectively. Individual Track Processing (Audio FX) Start with Pultec EQP-1A for tonal shaping of kick drums, bass, and vocals</li> Follow with LA-2A for natural, musical compression on vocals, bass, and guitars</li> </ul> Group Processing (Buses) Use Pultec on instrument buses (drum bus, vocal bus) to add cohesive tonal character</li> Apply SSL G Bus Compressor to submix buses for punch and glue</li> Send multiple sources to Lexicon 224 on an Aux track for shared spatial processing</li> </ul> Mix Finishing (Master Track) Insert SSL G Bus Compressor early in the master chain for overall mix cohesion</li> Add Pultec for final tonal sweetness and harmonic enhancement</li> Finish with Ampex ATR-102 as the final "analog finish" before limiting</li> </ul> What makes Universal Audio's emulations special is not just their sonic accuracy, but how they encourage you to work in the way professional studios have for decades. Each plugin embodies decades of engineering wisdom in its design, teaching you not just what sounds good, but why it sounds good. Building this mastering-focused collection by taking advantage of UAD's sale was a worthwhile investment. These aren't just plugins—they're tools that connect modern digital workflows to the golden age of analog recording, bringing warmth, character, and musicality to every project. Sublime Text - 職人主義的ソフトウェアの美学と持続可能なビジネスモデル 2026-01-08T00:00:00+00:00 Table of Contents </summary> </details> Sublime Textは、高速性と簡潔さを重視したクロスプラットフォームのテキストエディタです。派手な統合機能や巨大なエコシステムを志向せず、「編集体験そのものの質」を最優先に設計されている点が最大の特徴といえます。 2008年にリリースされて以来、その圧倒的なパフォーマンスと洗練されたUIで多くの開発者に愛されてきました。かつてはAtomやBracketsといった競合が次々と登場する中でも独自の地位を確立していましたが、 2015年のVisual Studio Codeの登場によって状況は一変しました。 Microsoftの豊富なリソースとオープンソースモデルによって急速に機能を拡充したVS Codeは、瞬く間に開発者コミュニティの主流となったのです。 しかし、Sublime Textは市場シェアを失っても開発を継続し、現在も継続的にアップデートされています。それを可能にしているのが、独自のビジネスモデルと一貫した設計思想です。 2026年現在もBuild 4000番台の開発が進められており、その品質は今も一級品を保ち続けています。 1. 技術的・思想的特徴</h2> 1.1. 圧倒的なパフォーマンス</h3> 起動が非常に速い</li> 大規模ファイルや巨大リポジトリでも編集が軽快</li> 入力遅延がほぼ発生しない</li> </ul> Sublime Textの最大の強みは、何よりもそのパフォーマンスです。エディタを起動してから実際に編集を開始できるまでの時間は、ほとんどの環境で1秒以内に収まります。 VS CodeがElectronベースでJavaScriptエンジンの起動コストを伴うのに対し、Sublime TextはC++ とカスタムUIツールキットで実装されており、 OSネイティブに近い起動速度を実現しています。 また、数万行を超える大規模ファイルや、数十万ファイルを含む巨大なリポジトリでも動作が重くなることはほとんどありません。 GitのLinuxカーネルリポジトリのような巨大なコードベースでも、ファイル検索や全文検索が瞬時に完了します。これは独自の描画エンジンとインデックス機構によって実現されており、「常に軽いこと」を最優先事項として設計されているためです。 特に重要なのが、入力に対するレスポンスの速さです。キーボードからの入力が画面に反映されるまでの遅延が極めて少なく、タイピングの快適さが損なわれません。この「入力遅延のなさ」は、長時間コーディングを行う開発者にとって、想像以上に重要な要素となります。 1.2. ミニマルで静かな UI</h3> 不要なアニメーションや通知が少ない</li> 情報密度は高いが、視覚的ノイズが少ない</li> IDE的な自動介入を極力行わない</li> </ul> Sublime Textのユーザーインターフェースは、極めて静かです。近年のソフトウェアに多く見られる派手なアニメーションや、頻繁なポップアップ通知、自動的に表示されるヒントやサジェストといった「親切な機能」は最小限に抑えられています。 これは決して機能が貧弱だからではなく、ユーザーの集中を妨げない設計を意図的に選択した結果です。情報密度は高く保たれており、必要な情報はすぐにアクセスできますが、視覚的なノイズは徹底的に排除されています。エディタという道具が前面に出てくることなく、書いているコードそのものに集中できる環境が提供されているのです。 また、IDEによくある「自動的な修正」や「勝手な補完」といった介入も控えめです。開発者が意図しないコード変更や、予期しないフォーマットが適用されることはほとんどありません。これは一見不便に思えるかもしれませんが、自分の書いたコードを完全にコントロールしたい開発者にとっては、むしろ信頼できる特性となります。 1.3. 保守的で一貫した設計思想</h3> 等幅フォント・静的フォント前提</li> Variable Fontの軸指定や高度なタイポグラフィ機能は非対応</li> フォントフォールバックや複雑な文字組みも対象外</li> </ul> Sublime Textは、技術トレンドを積極的に追いかけるタイプのソフトウェアではありません。例えば、近年広まってきたVariable Font（可変フォント）の軸指定機能や、高度なタイポグラフィ機能には対応していません。また、複雑なフォントフォールバックや文字組み処理も、必要最小限にとどめられています。 これを見ると「技術的に遅れている」と感じるかもしれませんが、実際には異なります。これらの機能は確かに便利ですが、実装にはレンダリングエンジンの複雑化が伴い、結果としてパフォーマンスの低下を招きます。Sublime Textは、パフォーマンス低下を招く機能を意図的に排除している のです。 この姿勢は、ソフトウェア全体に一貫しています。新機能を追加する際には、常に「これはパフォーマンスに影響するか」「これは本当にエディタに必要な機能か」という問いが立てられ、慎重に判断されています。結果として、機能の追加ペースは遅いものの、一度実装された機能は安定しており、長期間にわたって同じように動作し続けます。 1.4. 拡張は可能だが、万能ではない</h3> Pythonによるプラグイン拡張</li> LSP対応により、現代的な言語サポート機能は充実</li> ただしIDE全体としての統合度はVS Codeに及ばない</li> エコシステムは小規模</li> </ul> Sublime Textには、Pythonによるプラグイン機構が備わっており、機能を拡張可能です。Package Controlというパッケージマネージャーを使えば、コミュニティが開発した様々なプラグインを簡単にインストールできます。また、Language Server Protocol (LSP) にも対応しており、現代的なコード補完や定義ジャンプ、型チェックといった言語サポート機能は充実しています。 しかし、VS Codeのような統合開発環境としてのトータルな統合度を期待すると、物足りなさを感じるかもしれません。デバッガやターミナル、バージョン管理といった周辺機能の統合度や、拡張機能エコシステムの規模では、VS Codeには及びません。 エコシステムも、VS Codeの巨大なマーケットプレイスと比べれば小規模です。しかし、これも設計思想の表れといえます。Sublime Textは「プラットフォーム」になることを目指しておらず、あくまで「高品質なエディタ」であり続けることを選択しているのです。必要十分な拡張性は保ちつつ、複雑化や肥大化は避けるというバランスが取られています。 2. 継続的な開発と進化</h2> Sublime Textは市場シェアを失った後も、着実に開発を継続しています。2024年から2025年にかけても、複数の重要なアップデートがリリースされており、「保守的」でありながらも「停滞していない」ことを示しています。 2.1. 最近の主要アップデート</h3> Build 4200（2025年5月リリース） 2025年5月21日にリリースされたBuild 4200では、以下の重要な変更が含まれています。 Python プラグインの近代化: Python 3.3のサポート終了を段階的に開始し、Python 3.8への移行を進めている。さらに、次の開発サイクルではPython 3.13への移行が計画されており、プラグインエコシステムの技術的負債を解消する取り組みが進められている。 </li> OS サポートの見直し: 将来のバージョンでは、macOSの最低要件が10.9から10.13に引き上げられる。また、Windows 7、8、8.1のサポートが終了し、Windows 10以降が最低要件となる。この変更により、より新しいOS機能を活用できるようになる。 </li> UI の柔軟性向上: サイドバーを右側に配置できる sidebar_on_right</code> 設定が追加される。これは小さな変更に見えるが、長年のユーザー要望に応えたもの。 </li> ビルドシステムの強化: ビルドシステムで "interactive": true</code> を指定することで、インタラクティブな入力ボックスを表示できるようになった。これにより、コンパイル時の引数指定などがより便利になっている。 </li> 構文ハイライトの刷新: SQL、ActionScript、Diff、Bash、Graphvizの構文ハイライトが書き直され、より正確で高速になった。また、ZshとTOMLの構文ハイライトが新たに追加されている。 </li> </ul> Build 4180（2024年8月リリース） 2024年8月12日にリリースされたBuild 4180では、プラットフォーム固有の問題に対応しています。 Linux: KDE環境でのドラッグ＆ドロップ問題への対処（kwin 6.0.4でも修正済み）</li> Windows: スクロールバーをドラッグした際の動作改善</li> その他、複数のバグ修正</li> </ul> 2.2. Language Server Protocol（LSP）サポートの充実</h3> Sublime TextのLSPサポートは、近年大きく進化しています。Package Controlから利用できる LSP パッケージ</a>は、VS Codeと同等の高度な言語サポートを実現しています。 主要な言語サーバーには、以下のようなものがあります。 LSP-typescript / LSP-javascript: TypeScriptとJavaScriptのサポート</li> LSP-pyright / LSP-pylsp: Pythonの型チェックと補完</li> LSP-rust-analyzer: Rustの高度なIDE機能</li> LSP-intelephense / LSP-Phpactor: PHPの補完と定義ジャンプ</li> LSP-clangd: C/C++ の高度な補完</li> LSP-json / LSP-css / LSP-html: Web開発のサポート</li> LSP-angular / LSP-vue: モダンなフロントエンドフレームワーク</li> </ul> これらのヘルパーパッケージは、言語サーバーの自動インストールと設定を簡単にし、追加機能も提供しています。例えばLSP-pylspは2025年12月にも更新されており、エコシステムが活発に維持されていることがわかります。 興味深いのは、Sublime TextのLSP実装は同じファイルタイプに対して複数の言語サーバーを同時に実行できる点です。例えば、Pythonプロジェクト内のLSP-pyrightで一般的な機能を使いつつ、LSP-ruffでリンター警告を同時に表示するといった使い方が可能です。 このように、Sublime Textは「保守的」な設計思想を保ちながらも、現代的な開発環境に必要な機能を着実に取り込んでいます。急激な変化は起こりませんが、必要な進化は確実に続けられているのです。 3. 市場における位置づけ</h2> かつては高速GUIエディタの代表格</li> 現在はニッチだが評価の高い存在</li> VS Codeのような統合開発環境とは競争しない立場</li> </ul> 2010年代前半、Sublime Textは高速なGUIエディタの代表格として、多くの開発者に愛用されていました。TextMateの後継とも目され、Macユーザーを中心に広く普及していたのです。その影響力は大きく、VS Codeの初期バージョンはSublime Textのキーバインドやショートカットを参考にしたとも言われています。 しかし現在では、市場シェアという観点では完全にニッチな存在となりました。Stack Overflowの開発者調査でも、利用率は数パーセント程度にとどまっています。それでも、使い続けているユーザーからの評価は一貫して高く、「速さ」「安定性」「シンプルさ」を求める開発者の間では根強い支持を得ています。 興味深いのは、Sublime Textのユーザー層です。多くは、日常的にNeovimやEmacsといったCLIエディタを使いつつ、GUIが必要な場面や、より視覚的な操作が適している場面でSublime Textを併用しています。つまり、「メインのIDE」として使うのではなく、職人的な開発者の道具箱の中の1つとして位置づけられているのです。 VS Codeのような統合開発環境とは、もはや直接競争する立場にありません。機能の豊富さや拡張性では勝負せず、「軽快さ」「シンプルさ」「信頼性」という独自の価値を提供し続けることで、固有のポジションを確立しています。 4. ビジネスモデル</h2> Sublime Textが長期にわたって開発を継続できているのは、独自のビジネスモデルによるところが大きいです。多くのソフトウェアが無料化やサブスクリプションモデルに移行する中、Sublime Textは独自の道を歩んでいます。 4.1. 買い切り型ライセンス + 更新権</h3> 一度購入すれば永続的に使用可能</li> 購入時点から約3年間のアップデート権 が付与される</li> 更新権が切れても使用不可にはならない</li> 新しいメジャー版や最新ビルドを使いたい場合のみ再購入</li> </ul> Sublime Textのライセンスは、買い切り型を基本としています。一度購入すれば、そのバージョンは永続的に使用可能です。ただし、購入時点から約3年間のアップデート権が付与され、その期間内にリリースされた新バージョンには無料でアップグレードできます。 重要なのは、更新権が切れても、ソフトウェアが使用不可になることはない点です。購入時のバージョンは引き続き使用でき、セキュリティアップデートなどの重要な修正も提供されます。新しいメジャーバージョンや最新機能を使いたい場合にのみ、ライセンスを再購入すればよいのです。 このモデルは、月額・年額で支払い続けなければ使えなくなるSaaS的なサブスクリプションとは明確に異なります。ユーザーは「払い続けなければ使えなくなる」というプレッシャーから解放され、自分のペースでアップグレードを判断できます。一方で、開発側も定期的な収入が見込めるため、持続可能な開発が可能になっています。 4.2. 非 SaaS・低固定費構造</h3> クラウドサービスではない</li> 常時稼働サーバや大規模インフラが不要</li> 開発チームは少人数</li> 営業・マーケティングコストが極小</li> </ul> Sublime Textのもう1つの強みは、極めて低い固定費構造にあります。Sublime Textはクラウドサービスではなく、ユーザーのローカル環境で完結するスタンドアロンアプリケーションです。そのため、常時稼働するサーバーインフラや、大規模なデータセンターといった継続的なコストが一切発生しません。 開発チームも非常に小規模で、創設者のJon Skinner氏を中心とした数名程度で運営されていると言われています。大規模な開発組織を抱える必要がなく、人件費も抑えられています。 また、営業やマーケティングにも積極的に投資していません。広告を出すこともなく、口コミとブランド力だけで販売を続けています。Sublime Textの公式サイトは極めてシンプルで、派手なマーケティングメッセージもありません。 この結果、ユーザー数が爆発的に増えなくても黒字が成立する構造になっています。年間数万人程度のライセンス購入があれば、十分に開発を継続できるのです。これは、成長至上主義に陥らず、持続可能な開発を可能にする重要な要素となっています。 4.3. 法人・プロユーザーによる支え</h3> 個人購入に加え、法人でのまとめ買い</li> 経費精算による定期的な更新</li> 長期利用を前提としたユーザー層</li> </ul> Sublime Textのユーザーには、個人利用だけでなく、法人でのまとめ買いも多いと考えられます。開発チームが一斉にライセンスを購入するケースや、企業の標準ツールとして採用されているケースもあります。特に、パフォーマンスや安定性を重視する企業にとって、Sublime Textは魅力的な選択肢となります。 また、プロフェッショナルな開発者が多いため、ライセンスを経費として精算し、定期的に更新する傾向があります。個人で$99を支払うのは躊躇するかもしれませんが、会社の経費であれば、更新のハードルは下がります。 Sublime Textのユーザーは、長期利用を前提としている傾向が強いです。一度使い始めたら、数年から十年以上にわたって使い続けるユーザーが多いのです。これは、Sublime Textの安定性とシンプルさが、長期的な信頼を生んでいることを示しています。 一人あたりのLTV（顧客生涯価値）は、サブスクリプションモデルと比べると低めですが、非常に安定しています。ユーザーの離脱率が低く、定期的な更新が見込めるため、予測可能な収益構造となっているのです。 4.4. 成長を前提としない経営姿勢</h3> ベンチャーキャピタルに依存しない</li> 利用データの収集・広告モデルなし</li> ユーザー数や市場シェアの拡大を至上命題としない</li> </ul> Sublime Textの最も特徴的な点は、成長を前提としない経営姿勢にあります。ベンチャーキャピタルからの資金調達を受けておらず、外部投資家からの「成長しろ」というプレッシャーとは無縁です。そのため、ユーザー数を爆発的に増やすことや、市場シェアを最大化することを目標とする必要がありません。 また、ユーザーの利用データを収集して分析したり、広告モデルで収益化したりといったことも一切行っていません。Sublime Textは、インターネット接続を必要とせず、ローカル環境で完結するため、プライバシーの観点でも安心できます。テレメトリデータの送信もなく、ユーザーがどのような使い方をしているかは開発者にはわかりません。 この経営姿勢は、現代のスタートアップ文化やシリコンバレーの常識とは真逆です。「急成長」「ユニコーン」「市場の独占」といった価値観とは距離を置き、その代わりに**「小さく、長く、静かに続ける」**ことを選択しています。 これは、短期的な利益最大化ではなく、長期的な持続可能性を重視した結果です。派手さはありませんが、10年後、20年後も同じように開発が続いている。そんな可能性を信じさせてくれるのが、Sublime Textなのです。 5. Sublime Merge - 同じ思想の Git クライアント</h2> Sublime HQは、テキストエディタのSublime Textだけでなく、Gitクライアントの Sublime Merge も開発しています。Sublime Mergeは、Sublime Textと同じ設計思想をGitクライアントに適用したソフトウェアです。 Sublime Mergeの特徴も、Sublime Textと共通しています。 起動が非常に速く、大規模リポジトリでも軽快に動作する</li> UIがシンプルで、視覚的なノイズが少ない</li> 複雑なGit操作も、キーボード中心の操作で素早く実行できる</li> 独自のマージツールが優れており、コンフリクト解決が快適</li> </ul> Gitクライアントの世界でも、GitKrakenやSourceTreeといった多機能なGUIツールが主流となっていますが、Sublime Mergeはそれらとは異なるアプローチを取っています。必要な機能に絞り込み、パフォーマンスと操作性を優先した結果、Gitの複雑な操作を快適に行えるツールとなっています。 ビジネスモデルもSublime Textと同様で、買い切り型ライセンス + 約3年間の更新権という形式です。Sublime TextとSublime Mergeをセットで購入すると割引が適用されるバンドルライセンスも提供されています。 私自身も、Sublime Textの思想に共鳴し、今回Sublime Textのライセンスを更新すると同時に、Sublime Mergeのライセンスも購入しました。どちらも、長く使い続けられる信頼できるツールだと感じています。 6. 評価と総括</h2> Sublime Textは次のようなソフトウェアです。 主役ではなくなったが、品質は今も一級品</li> 時代の要請すべてには応えないが、軸はぶれない</li> 利便性よりも、編集体験の純度を重視</li> 商業的成功よりも、持続可能性を優先</li> </ul> その結果として、 「勢いはないが、消えもしない」 </blockquote> という独特のポジションを確立しています。 現代のソフトウェア業界では、「より多くの機能」「より大きなエコシステム」「より速い成長」が正義とされがちです。しかし、Sublime Textはそれとは異なる価値観を示しています。機能を抑制し、シンプルさを保ち、持続可能な開発を優先することで、長期的な信頼を獲得しているのです。 このアプローチは、すべてのソフトウェアに適用できるわけではありません。しかし、少なくとも「開発ツール」という領域においては、十分に成立する戦略であることを、Sublime Textは証明しています。 Sublime Textは、現代では稀少になった職人主義的ソフトウェアと、そのビジネスモデルの実例です。派手さはありませんが、確かな品質と一貫した思想を持ち続けることで、静かに、しかし確実に生き残っているのです。 Archetype: Cory Wong X 2025-11-24T00:00:00+00:00 Neural DSPのブラックフライデーセールが始まったので、Archetype: Cony Wong X</a>を購入しました。 </iframe> Yostos</a> · Feel Like Making Love</a></div> アンプが3タイプあるのでテストしてみました。次のように弾き分けています。 バッキングと最初のギターはコンソール直挿しをシミュレートしたD.I. Funk Console</li> 2番目はThe Postal Serviceというエンベロープフィルターをオンにして、The Clean MachineというおそらくローランドのJC-120をモデリングしたアンプ</li> 3番目はDumbleをモデリングしたThe Amp Snobでディストーションサウンド</li> </ul> まとめ</h2> Archetype: Cory Wong Xは、ファンクギターに特化したプラグインではありますが、3つのアンプモデルそれぞれが異なるキャラクターを持っており、クリーントーンからディストーションまで幅広いサウンドを作ることができます。特にD.I. Funk Consoleはコンソール直挿しのタイトなサウンド、The Clean Machineはクリアで煌びやかなトーン、The Amp Snobは温かみのあるオーバードライブサウンドが特徴的です。ファンク以外のジャンルでも十分に活用できる汎用性の高いプラグインだと感じました。ブラックフライデーセールではArchetype: Pliniも合わせて購入しました。 Neural DSP Archetypeプラグインを買おう 2025-11-16T00:00:00+00:00 Archetype シリーズとは</h2> Archetypeシリーズは、Neural DSP社が開発するプラグインで、PC/Mac上でギターアンプやエフェクターっを再現するソフトウェアです。 このジャンルの先駆けとなったIK MultimediaのAmplitubeも持っていますが、Amplitubeが膨大なアンプとエフェクターに対応した総合的なアンプシミュレーターであるのに対し、Archetypeシリーズはアーチストの名を冠したラインナップに分れており、そのアーチストに特化した数種類のアンプとエフェクターが厳選されています。 個人的に以下の点を評価しています。 厳選したモデルをリアルに再現したアンプモデリング技術</li> アーチストのスタイルに特化した実用的な機材の組み合わせに厳選</li> 高音質の割りにCPU負荷が軽い</li> </ul> Amplitubeが「広く浅く」多くのジャンルに対応しているのに対して、「狭く深く」特定ジャンルに特化しています。 購入候補</h2> Neural DSPの過去のブラックフライデーセールを確認すると、 2022年は11月18日、22023年は11月17日、024年は11月24日にセールが始まったようです。よって、今年も今週か遅くとも来週にはセールがあると予想できます。どのプラグインを購入するか決めなければなりません。 現在検討しているのは以下の2つです。 Archetype: Cory Wong X</h3> Archetype: Cory Wong X</a>は、 Vulfpeck（ヴァルフペック）のギタリストでファンクギターの代表的存在としてクリーントーンの美学と完璧主義的な音作りで「モダンギターヒーロー」と称されているCory Wongの機材をシミュレートしたプラグインです。 クリーントーンからローゲインまでカバーでき、なかなか極まらないファンクなカッティングに適した音が直ぐに出せます。ブースターとオーバードライブをオンにしてThe Amp Snobを選べば、激しめのリードもこなせそうです。 Pre Effect</h4> Wah - MIDI対応のワウペダル（オートワウ機能付き）</li> The Postal Service - エンベロープフィルター</li> The 4th Position Compressor - Coryのシグネチャーコンプレッサー</li> The Tuber - チューブアンプファン向けの改造ブースター</li> The Big Rig Overdrive - ファズ寄りの強力なオーバードライブ</li> </ul> Amp</h4> D.I. Funk Console - アナログチャンネルストリップベース、チューブサチュレーション/コンプレッサー/EQ/フィルター搭載。その名の通りコンソール直の音をシミュレートしており貴重</li> The Clean Machine - 業界最高のクリーンアンプを集約したカスタムアンプ。おそらくRoland Jazz Chorusがモデル</li> The Amp Snob - 希少なアンプのモデル、クリーンから歪み手前まで対応。Dumbleアンプがモデル</li> </ul> Post Effect</h4> The 80s - 80年代風ヴィンテージコーラス</li> Delay-y-y - アナログ回路ベースのBBDディレイ</li> The Wash - シマー機能付きリバーブ</li> </ul> Archetype: Plini X</h3> Archetype: Plini X</a>は、プログレッシブ、フュージョン、メタルのブレンドサウンドに特化した汎用性の高いプラグインです。 アンプの前にディレイがあるのは魅力的ですね。 Pre Effect</h4> Compressor - バスコンプのモデル</li> Octaver（新機能）- オクターブ上下のブレンド</li> Drive（更新版）- ブースト/オーバードライブ、ファズスイッチ追加</li> Delay（新機能）- ディープなアンビエンス用</li> </ul> Amp</h4> Clean - 透明でパンチのあるクリーンアンプ。Fender Twin + Dumbleのミックス</li> Crunch - クリーンとハイゲインの中間、ブリティッシュトーン。Friedman BE-100 (BEチャンネル)</li> Lead - Crunchにゲインステージ追加、リード/ヘヴィリフ向け。Friedman HBE + EVH 5150/5153のミックス</li> </ul> Post Effect</h4> Chorus（新機能）- ヴィンテージ80s/モダン空間系の2モード</li> Delay（更新版）- テープサチュレーション/モジュレーション搭載</li> Reverb - 多次元リバーブ</li> </ul> まとめ</h2> Cory Wongは購入確定なので、残る選択肢を整理します。歪み系ならPliniかなと思っていますが、Nollyも気になっています。 Pliniはクリーンからハイゲインまで汎用的で、プログレ・フュージョン・メタルと幅広く対応します。Cory Wongと組み合わせれば、クリーンから激しい歪みまでシームレスにカバーできるでしょう。 一方Nollyはモダンメタル特化で、4種類のアンプと640のIRを搭載し、より攻撃的なサウンドに強みがあります。既にCory Wongでクリーンが確保できているなら、ハイゲインに振り切ったNollyも魅力的です。 ブラックフライデーセールは11月末頃から始まり半額になる可能性が高いため、全て14日間無料トライアルで試して今週中に決断せねば。 Scaler3で作曲支援 2025-05-31T00:00:00+00:00 先日発売されたScaler3ですが、音楽理論を知らなくても作曲や編曲ができると話題なので購入してみました。 Table of Contents</summary> </details> ## Scaler3とは Scaler3</a>は音楽理論やコード理論がわからなくても凝ったコード進行が作れる作曲支援ソフトです。 裏では音楽理論に基づいて適切なコード進行を提案してくれるのその中から気に入ったコードをどんどんドラッグしてコード進行を作っていけます。 「コードに合う違和感のない音はどれか」「コード進行で冒険したいが、このコードは適切か」といったプロでも抱えてしまいそうな悩みを解消してくれます。 Scaler3を検証してみた</h2> 今回は既存のメロディを取ってきてSuggest機能に従ってコード進行を作ってみました。使用したのはThe Banglesの"Eternal Flame"です。 またScaler3から追加されたアレンジ機能を使って伴奏を付けています。ドラムの生成機能はないので、ドラムだけはLogic ProのPlayer機能を使っています。 前半がScaler3で生成した伴奏、後半がオリジナルのコード進行に従った伴奏です。 オリジナルは、G Majorで次のようなコード進行です。 G Em7 | C D | G Em7 | C D | Em B7 | Em7 A7 | D Bm7| Am7</code></pre> ですが、 Scaler3でもっともノートとコードにのマッチ度が高かったB Phrygian Modeでコードを構成してみました。 Bm G | C D | Em G | Am G | Em7 Dsus2 | Bm Em | A7 D| Bm7</code></pre> メロディから判断され推奨されるコードはブルーで示されますが、メロディをすべてマッチするわけではないんで、実際は推奨コードから試しながら決めていくことになります。しかし、何も参考にせず自分で考えるより数倍生産性は上がります。 オリジナルのほうが安心して聞ける印象です。一方、Scaler3で作ったコード進行はちょっと印象が違っていますが、まぁ成り立っているのではないでしょうか。 多分、メロディからコードを作るより、コード進行をScalerで練って、メロディを提案してもらったほうがうまく働くと思います。 まとめ</h2> Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。 🎯 習得難易度について</h3> 完全な素人には難しいものの、基本的な音楽理論（メジャー・マイナー、ダイアトニックコードなど）を理解していれば十分活用できます。転調の提案など高度な機能については、理論と感性のバランスを取りながら使い分けることが重要です。 💡 Scaler3の真価</h3> 最大の価値は「0→1の創作支援」 にあります。白紙の状態から音楽理論に基づいた膨大なコード進行のアセットを参考にできるため、創作の起点として非常に強力です。また、安全圏を抜け出した「冒険的なコード進行」への挑戦も、理論的裏付けがあるので安心して試せます。 🤖 AI作曲時代における位置づけ</h3> AIが楽曲を自動生成する時代になりましたが、創作者が主導権を握りながら音楽理論の恩恵を受けられるScaler3のようなツールは、まだまだ重要な役割を果たすでしょう。 完全自動化ではなく、人間の創意工夫とテクノロジーの協働による作曲スタイルは、今後も価値を持ち続けると考えられます。 結論として、Scaler3は音楽制作の生産性を大幅に向上させる優秀なパートナーツールです。 Synthersizer V Studio 2 Pro 2025-04-15T00:00:00+00:00 とりあえず、昨年Synthersizer V 1で作った藤原さくらさんの「Just One Girl</a> 」をSynthesizer V 2でヴォーカル部分をリテイクしてみました。 </iframe> </div> 以前のバージョンでもかなりリアルなヴォーカルなのであまり改善点がわからないかもしれませんが、以下に変更点をまとめておきます。 Sythesizer V Studio 2 Proの変更点</h2> 次のような変更がなされています。 歌声生成速度の改善</h3> Synthesizer V 2では歌声の生成速度が改善され、以前のSynthesizer Vに比べると300% 速くなったとのことです。 以前のバージョンでは編集時にノート1つ音程を変更しただけで少し待たないと再生できませんでしたが、 Synthesizer V 2では、ノートの編集後に再生できるまでの時間が短くなり待たされるという感覚がほぼありません。 新しいボーカルモードの機能</h3> ボーカルモードはシンガーの歌声にバリエーションを持たせる機能ですが、 Synthesizer V 2では各パラメータが「ピッチ(Pitch)」「音色(Timbre)」「発声 (Pronun)」へと分解可能となりました。 これにより、ピッチに関しては「Clear」スタイルを強く適用するけれど発声は「ソフト」スタイルを強くするなど、細かやかな調整が可能となりました。 AIリテイク機能の改善</h3> AIリテイクは、AIの技術を用いて異なる歌い方を生成できる機能です。 以前のバージョンでは、「ピッチ」と「声色」のみがリテイク可能でしたが、 Synthesizer V 2から「タイミング」も生成できるようになりました。 AIリテイク生成時のパラメータはXYパッドのようなインターフェイスとなり、「Vibrant」「Refined」「Stable」「Raw」をコントロールする方式となりました。より直感的に音を調整できます。 スマートピッチコントロール</h3> 以前のSyhthesizer Vでは、ピッチ関係のパラメータは「ピッチ推移」や「ビブラート」がありましたが、どのように変化するか分かりづらいものがありました。 V2ではピアノロール状でピッチ制御点を直接追加できます。制御点を通るピッチカーブが自動生成され、制御点をドラッグするとリアルタイムにカーブが変化します。これまでよりずいぶんと分かりやすくなりました。 アクティベーション方法の変更</h3> これまでアクティベーションコードを製品に入力する方式だったと思いますが、今回からDreamtonicsのアカウントと紐付いて製品がアクティベーションを行うようになりました。 従ってDreamtonicsのアカウントを作成し、そこに製品登録をきちんとやっておく必要があります。 まとめ</h2> 以前のバージョンでもかなりリアルなヴォーカルを生成できましたが、今回のバージョンアップでより細かなコントロールが可能となりました。 私自身はそこまでヴォーカルを調整することはありませんが、エンジンとデータベースを更新するだけでも以前不自然だった部分がかなり改善されます。 円安でちょっと高いですが、バージョンアップの価値はあると思います。 textlintで日本語ブログの品質を向上させよう 2025-03-23T00:00:00+00:00 textlintとは</h2> textlint</a>は、テキスト上の問題を洗い出すための静的解析ツールです。特に日本語のテキスト校正において優れた機能を持っており、文章のスタイル、用語の統一、表記ゆれ、誤字脱字などをチェックできます。 Markdownファイルなどの構造化されたテキストファイルに対して適用できるため、ブログ記事や技術文書の品質を向上させるのに最適です。 なぜtextlintを導入したのか</h2> 技術ブログを書く際に直面する問題は、以下のようなものがあります。 「ですます調」と「である調」の混在</li> 全角と半角の間のスペースの不統一</li> 句読点や括弧の前後の余計なスペース</li> カタカナ語の間に中黒（・）や半角スペースがない</li> </ul> これらの問題は、読者にとって違和感を与え、プロフェッショナルさを損なう可能性があります。textlintを導入することで、これらの問題を自動的に検出し、一貫した文章スタイルを維持できるようになります。 インストールと設定</h2> 1. 必要なパッケージのインストール</h3> 次のコマンドでtextlintと必要なルールをインストールします。 npm install --save-dev textlint \ textlint-rule-preset-ja-spacing \ textlint-rule-preset-ja-technical-writing \ textlint-rule-no-mix-dearu-desumasu \ textlint-filter-rule-comments \ textlint-filter-rule-node-types \ textlint-plugin-mdx</code></pre>2. .textlintrc</code>の設定</h3> プロジェクトのルートディレクトリに.textlintrc</code>ファイルを作成し、以下のように設定します。 { "filters": { "comments": true, "node-types": { "nodeTypes": ["jsx", "code", "inline-code", "html", "BlockQuote"] }, "allowlist": { "allow": [ "/<blockquote[^>]*>[\\s\\S]*?<\\/blockquote>/", "/<blockquote>([\\s\\S])*?<\\/blockquote>/g" ] } }, "plugins": ["mdx"], "rules": { "preset-ja-spacing": { "ja-nakaguro-or-halfwidth-space-between-katakana": true, "ja-no-space-around-parentheses": true, "ja-no-space-between-full-width": true, "ja-space-between-half-and-full-width": { "space": "always", "exceptPunctuation": true }, "ja-space-after-exclamation": true, "ja-space-after-question": true, "ja-space-around-code": false }, "preset-ja-technical-writing": { "sentence-length": { "max": 200 }, "no-exclamation-question-mark": { "allowHalfWidthQuestion": true, "allowFullWidthQuestion": true }, "ja-no-weak-phrase": false, "max-kanji-continuous-len": { "max": 20 }, "ja-no-mixed-period": { "allowPeriodMarks": ["箇条書き", "リスト", "。", "、", "」"], "forceAppendPeriod": false, "checkBlockQuote": false, "checkListItem": false, "allowExceptionContext": true, "ignorePeriodInQuotation": true } }, "no-mix-dearu-desumasu": { "preferInHeader": "である", "preferInBody": "ですます", "preferInList": "である", "strict": false }, "@textlint-rule/textlint-rule-no-invalid-control-character": false, "ja-technical-writing/no-doubled-conjunction": false, "ja-technical-writing/no-doubled-conjunctive-particle-ga": false } }</code></pre>3. package.jsonにスクリプトを追加</h3> { "scripts": { "check": "textlint \"src/app/articles/**/*.mdx\"" } }</code></pre>設定の詳細解説</h2> フィルター</h3> MDXファイルには、本文の他にJSXコンポーネントやコードブロックが含まれています。これらに対してtextlintのルールを適用すると誤検出が多発します。そのため、フィルターを設定して特定の部分をチェック対象から除外しました。 "filters": { "comments": true, "node-types": { "nodeTypes": ["jsx", "code", "inline-code", "html", "BlockQuote"] }, "allowlist": { "allow": [ "/<blockquote[^>]*>[\\s\\S]*?<\\/blockquote>/", "/<blockquote>([\\s\\S])*?<\\/blockquote>/g" ] } }</code></pre> comments</code>: コメント部分をチェック対象から除外</li> node-types</code>: JSX、コードブロック、インラインコード、HTMLタグ、引用文をチェック対象から除外</li> allowlist</code>: 正規表現で指定したパターンをチェック対象から除外</li> </ul> blockquote要素内の引用文は自分の文章でなく修正しようもないため、対象から外しています。 ルール</h3> 1. 「ですます調」と「である調」の統一 (no-mix-dearu-desumasu)</h4> 文体の一貫性を保つためのルールです。 "no-mix-dearu-desumasu": { "preferInHeader": "である", "preferInBody": "ですます", "preferInList": "である", "strict": false }</code></pre> 見出しは「である調」とする</li> 本文は「ですます調」とする</li> リストは「である調」とする</li> strict: false</code>で厳密すぎるチェックを回避する</li> </ul> 2. 日本語の間隔に関するルール (preset-ja-spacing)</h4> "preset-ja-spacing": { "ja-nakaguro-or-halfwidth-space-between-katakana": true, "ja-no-space-around-parentheses": true, "ja-no-space-between-full-width": true, "ja-space-between-half-and-full-width": { "space": "always", "exceptPunctuation": true }, "ja-space-after-exclamation": true, "ja-space-after-question": true, "ja-space-around-code": false }</code></pre> カタカナ語の間には中黒または半角スペースを入れる規則である</li> 括弧の前後には余分なスペースを入れない規則である</li> 全角文字の間にはスペースを入れない規則である</li> 半角と全角の間には常にスペースを入れる規則である（句読点は例外）</li> 感嘆符と疑問符の後にはスペースを入れる規則である</li> コードの前後のスペースは不要とする規則である</li> </ul> 3. 技術文書向けのルール (preset-ja-technical-writing)</h4> 技術文書に適した日本語表現をチェックする包括的なルールセットです。冗長な表現、読みにくい文章構造、一文の長さなどをチェックする。以下のような設定を追加しています。 max-kanji-continuous-len</code>: 漢字の連続使用を20文字までに制限を緩和</li> 助詞の重複や冗長表現、不自然なアルファベット使用などを検出する機能を含む</li> 技術文書らしい表現をチェックし、読みやすさを向上させる</li> </ul> MDXファイルの対応と実行時の問題解決</h2> Next.jsのブログでは、多くの場合MDXファイルを使用しています。デフォルトのtextlint設定ではMDXファイルを認識できないことがあります。実際にnpm run check</code>を実行してみると、以下のようなデバッグ情報が表示されました。 No Process files that are un-support extensions: ["/path/to/your/blog/src/app/articles/.../page.mdx",...]</code></pre> この問題を解決するには、前述のインストール手順にあるように、textlint-plugin-mdx</code>パッケージを追加し、.textlintrc</code>ファイルの設定に"plugins": ["mdx"]</code>を追加する必要があります。 正しく設定した後の実行結果</h3> 正しく設定した後、npm run check</code>を実行すると、ブログ内のMDXファイルが検査され、以下のような結果が表示されます。 /path/to/your/blog/src/app/articles/.../page.mdx 23:138 ✓ error 原則として、全角文字と半角文字の間にスペースを入れます。 ja-spacing/ja-space-between-half-and-full-width 27:32 error 文末が"。"で終わっていません。 ja-technical-writing/ja-no-mixed-period 40:7 ✓ error 原則として、全角文字と半角文字の間にスペースを入れます。 ja-spacing/ja-space-between-half-and-full-width 167:15 ✓ error かっこの外側、内側ともにスペースを入れません。 ja-spacing/ja-no-space-around-parentheses 167:41 error 箇条書き: "である"調でなければなりません no-mix-dearu-desumasu</code></pre> チェックマーク（✓）がついているエラーは自動修正可能なものです。これらを一括修正するには、以下のコマンドを実行します。 npx textlint --fix "src/app/articles/**/*.mdx"</code></pre> ただし、すべてのエラーが自動修正できるわけではありません。特に文体（「ですます調」と「である調」）や文末の句点、文の長さなどに関するエラーは、意図に合わせて手動で修正する必要があります。 CI/CDパイプラインへの組み込み</h3> 品質チェックを自動化するために、GitHub Actionsなどのワークフローにtextlintを組み込むこともできます。例えば、以下のような.github/workflows/textlint.yml</code>ファイルを作成することで、プルリクエスト時に自動的に文章をチェックできます。 name: Textlint on: pull_request: paths: - "src/app/articles/**/*.mdx" jobs: textlint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: "20" cache: "npm" - run: npm ci - run: npm run check</code></pre>期待される効果</h2> textlintを導入することで得られる主な効果は以下の通りです。 一貫した文体: 文体が混在しない文章になる</li> 読みやすさの向上: 適切な空白や区切りにより、読みやすい文章になる</li> プロフェッショナルな印象: 表記の一貫性により、プロフェッショナルな印象を与える</li> 効率的な校正: 手動での確認作業が減り、効率的に校正できる</li> 品質の均一化: 複数の執筆者がいる場合でも、文章スタイルを統一できる</li> CI/CDパイプラインとの統合: Node.jsベースのツールであるため、GitHub ActionsやJenkins、AWS CodeBuildなどのCI/CDパイプラインに容易に組み込める</li> </ol> まとめ</h2> textlintは、日本語の技術ブログを書く際の強力な味方です。適切な設定により、文章の品質を向上させ、読者にとって読みやすく一貫性のある記事を提供できます。特にMDXを使ったブログでは、フィルター設定により、記事本文とコードやJSXを適切に区別してチェックできます。 Next.js + Tailwind Plus(旧Tailwind UI)をベースにしたブログシステムとの相性も抜群です。Node.jsベースのツールであるため、同じエコシステム内で簡単に導入でき、npmスクリプトとして実行できます。さらに、GitHub ActionsなどのCI/CD パイプラインに組み込むことで、プルリクエスト時に自動的に文章をチェックし、品質を担保も可能です。 今回紹介した設定は、MDXファイルを使ったNext.jsブログに最適化されていますが、他の形式の文書にも応用可能です。自分の文書スタイルや好みに合わせてカスタマイズしてみてください。 定期的にnpm run check</code>を実行し、指摘された問題を修正することで、ブログ記事の品質を着実に向上させることができます。 ChromaLensCLI: Command Line Color Accessibility Validation 2025-01-25T00:00:00+00:00 とりあえず色覚異常の方にも画像が正しく認識できてるか確認するためのツール ChromaLens CLI</code>を作ってみた。 ChromaLens CLIの使い方</h2> 使い方は、次の通り。 ./chromalens input.jpg output.jpg --type tritanopia</code></pre> これで色覚異常の方が実際どのようにインプットとなる画像が見えているかシミュレーションした画像が出力されます。 type</code> オプションの指定は次の通りです。 protanopia (1型色覚)</li> deuteranopia (2型色覚)</li> tritanopia (3型色覚)</li> </ul> ChromeLens CLIの環境設定</h4> 以下は、venvでPythonの仮想環境を作って必要なパッケージをインストールする手順です。 python3 -m venv venv source venv/bin/activate.fish pip install numpy Pillow</code></pre> 以下が実際のコードです。chromalens</code>というファイル名で保管ください。授業中に書いたコードなので、エラー処理などは省いています。 #!/usr/bin/env python3 from PIL import Image class ColorVisionSimulator: MATRICES = { 'protanopia': np.array([ [0.567, 0.433, 0.000], [0.558, 0.442, 0.000], [0.000, 0.242, 0.758] ]), 'deuteranopia': np.array([ [0.625, 0.375, 0.000], [0.700, 0.300, 0.000], [0.000, 0.300, 0.700] ]), 'tritanopia': np.array([ [0.950, 0.050, 0.000], [0.000, 0.433, 0.567], [0.000, 0.475, 0.525] ]) } def simulate(self, image_path, output_path, cvd_type): if cvd_type not in self.MATRICES: raise ValueError(f"Unsupported CVD type. Choose from: {', '.join(self.MATRICES.keys())}") # 画像を読み込み img = Image.open(image_path) # RGBAの場合はRGBに変換 if img.mode == 'RGBA': img = img.convert('RGB') # NumPy配列に変換 img_array = np.array(img) # 色変換行列を適用 matrix = self.MATRICES[cvd_type] shape = img_array.shape pixels = img_array.reshape(-1, 3) converted = np.dot(pixels, matrix.T) # 値を0-255の範囲に収める converted = np.clip(converted, 0, 255) converted = converted.reshape(shape) # 画像として保存 result = Image.fromarray(converted.astype('uint8'), 'RGB') result.save(output_path) def main(): parser = argparse.ArgumentParser(description='Color Vision Deficiency Simulator') parser.add_argument('input', help='Input image path') parser.add_argument('output', help='Output image path') parser.add_argument('--type', '-t', choices=['protanopia', 'deuteranopia', 'tritanopia'], required=True, help='Type of color vision deficiency') args = parser.parse_args() simulator = ColorVisionSimulator() try: simulator.simulate(args.input, args.output, args.type) print(f"Simulation complete: {args.output}") except Exception as e: print(f"Error: {str(e)}") exit(1) if __name__ == '__main__': main()</code></pre> LogSeq at a Glance: An Overview for Beginners 2025-01-01T00:00:00+00:00 Table of Contents</summary> </details> はじめに</h2> LogSeqとは何か、シンプルな説明</h3> LogSeqは、あなたの考えやアイデア、メモを自由に書き留め、それらをつなぎ合わせることができるデジタルノートアプリです。紙のノートとは違い、書いた内容を後から簡単に整理したり、関連する情報どうしをリンクでつなげたりできます。 特徴的なのは、以下の3つのポイントです。 箇条書きベースで書ける 考えたことを思いつくままメモできる</li> 後から簡単に整理できる</li> </ul> </li> 日付ごとにページが自動で作られる 日記のように、その日のことを記録できる</li> カレンダーのように過去の記録を見返せる</li> </ul> </li> ページ同士をつなげられる 関連する情報どうしを簡単にリンクできる</li> 新しい気づきや発見を見つけやすい</li> </ul> </li> </ol> なぜLogSeqが便利なのか</h3> LogSeqが便利な理由は、私たちの脳の働き方と合わせた設計にあります。 思考の自然な流れを妨げない 思いついたことを、その場でさっと書き留められる</li> 後でどこに書いたか探すことを気にせず、まずメモできる</li> 整理は後からでもできる</li> </ul> </li> 情報同士のつながりを自然に作れる 関連する情報を[[リンク]]</code>で簡単につなげられる</li> 一度つないだ情報は、双方向から見つけられる</li> 気づかなかった情報のつながりが自然と見えてくる</li> </ul> </li> 記憶と振り返りをサポート 日付ごとのページが自動で作られるので、いつ何を考えたかが残る</li> 過去の記録が自然とタイムライン化される</li> 定期的な振り返りが簡単にできる</li> </ul> </li> 知識が育っていく 書いた内容は単なる記録として終わらない</li> 新しい情報を追加するたびに、既存の知識とつながっていく</li> それによって新しい発見や気づきが生まれる</li> </ul> </li> </ol> つまり、LogSeqは「とりあえずメモ」から始めて、そこから自然と「つながりのある知識」を育てていけるツールなのです。 LogSeqの基本的な使い方</h2> 最初の画面の見方</h3> LogSeqを開くと、シンプルな画面が表示されます。画面の構成を理解しましょう。 左側のサイドバー ジャーナル（日付ごとのページ）へのリンク</li> お気に入りページの一覧</li> 全てのページ一覧</li> </ul> </li> メイン画面 現在の日付のページが自動で開</li> ここに自由に文章を書いていく</li> </ul> </li> 右側のサイドバー 開いているページに関連する情報が表示</li> リンクされているページの一覧なども表示</li> </ul> </li> </ul> 新しいページの作り方</h3> 新しいページを作るには2つの方法があります。 直接作成する方法 画面上部の検索バーに新しいページ名を入力</li> エンターキーを押すと、新しいページが作られる</li> </ul> </li> リンクから作る方法 文章の中に[[新しいページ名]]</code>と書く</li> 自動的にリンクが作られ、クリックで新しいページを作られる</li> </ul> </li> </ol> Markdownで記入する</h3> LogSeqでは、Markdownという書き方を使います。難しく考える必要はありません。以下のような基本的な書き方を覚えましょう。 見出しの書き方 大見出し # 中見出し ## 小見出し</code></pre> 文字の装飾 _斜体で書く_ **太字で書く** ~~打ち消し線~~</code></pre> 箇条書き - 箇条書き1 - 箇条書き1-1 - 箇条書き1-2 - 箇条書き2</code></pre> これらの書き方は、実際に使いながら少しずつ覚えていけば大丈夫です。最初は普通の文章を書くところから始めましょう。 日々のノート作成の基本</h2> 箇条書きの書き方</h3> LogSeqでは、箇条書きを基本としてノートを作成します。箇条書きには、以下のような特徴があります。 基本の書き方 行頭に「-」（ハイフン）と半角スペースを入力</li> Enterキーを押すと、自動的に次の箇条書きが始まる</li> Tabキーで階層を下げる（字下げ）</li> Shift + Tabで階層を上げる</li> </ul> </li> 箇条書きのコツ 1つの項目は短めに書く</li> 詳しい説明が必要な場合は、階層を下げて書く</li> 関連する内容は、同じ階層にまとめる</li> </ul> </li> </ul> 日付ページの使い方</h3> LogSeqでは、毎日自動的に日付のページ（ジャーナル）が作られます。 日付ページの特徴 起動時に自動的に今日の日付のページが開く</li> 左サイドバーの「Journals」から過去の日付を開ける</li> 日付ページには、その日に考えたことや行ったことを自由に書ける</li> </ul> </li> 効果的な使い方 朝：今日やることを箇条書きで書き出す</li> 日中：気づいたことや考えたことをメモ</li> 夜：その日の振り返りを書く</li> </ul> </li> </ul> タグの付け方と活用法</h3> タグは情報の整理と検索を助ける強力なツールです。ページリンクと組み合わせることで、より効果的な知識管理が可能になります。 タグの基本 単語の前に「#」（ハッシュ）を付ける</li> 例：#勉強 #アイデア #ToDo</li> スペースを含む場合は「#[[読書メモ]]</code>」のように[[]]で囲む</li> </ul> </li> タグとページリンクの特徴と使い分け タグ（#）の特徴 複数のページに共通する「性質」を示すのに適している</li> 一覧表示やフィルタリングが簡単</li> 例：#未完了、#重要、#要復習</li> </ul> </li> ページリンク([[]])の特徴 特定の「主題」についての詳細な記述に適している</li> 概念間の関係性を表現しやすい</li> 例：[[数学]]</code>、[[微分]]</code>、[[Newton]]</code></li> </ul> </li> </ul> </li> 効果的な併用方法 主題と性質を組み合わせる [[微分]]</code> のページに #数学 #要復習を付ける</li> [[読書記録]]</code> のページに #継続中 #インプットを付ける</li> </ul> </li> 概念の関係性を示す [[微分]]</code>のページで [[極限]]</code> と [[関数]]</code> を参照しつつ、#数学を付ける</li> [[Newton]]</code>のページで [[力学]]</code> を参照しつつ、#物理学者を付ける</li> </ul> </li> </ul> </li> </ul> このように、タグとページリンクはそれぞれの特徴を活かして使うことで、より効率的な知識管理が可能になります。 知識のつながりを作る</h2> ページ間のリンクの作り方</h3> LogSeqの強力な特徴は、ページ同士をつなげられることです。知識と知識を結びつけることで、新しい気づきが生まれやすくなります。 基本的なリンクの作り方 [[ページ名]]</code> と入力する（[[</code>と]]</code>で囲む）</li> リンク先のページがなければ、自動的に新しいページが作られる</li> エイリアスをつける場合：[[ページ名]][表示したい文字]</code> 例：[[アインシュタイン]][彼]</code>と書くと、「彼」と表示される</li> </ul> </li> </ul> </li> 効果的なリンクの付け方 重要な概念や用語が出てきたらリンクにする</li> 関連する話題が出てきたら積極的にリンクする</li> あとで詳しく書きたい内容があればリンクにする</li> </ul> </li> </ul> バックリンクの概念と確認方法</h3> バックリンクとは、「どのページからリンクされているか」を示す機能です。自動的に作られる双方向のつながりにより、知識の関係性が見えてきます。 バックリンクの特徴 自動的に作られる（手動で作る必要はない）</li> 右サイドバーに表示される</li> リンク元のページの該当部分が引用として表示される</li> </ul> </li> バックリンクの活用法 関連する記述を後から発見できる</li> 同じ概念が出てくる文脈を確認できる</li> 知識のunexpectedな関連性に気づける</li> </ul> </li> </ul> 関連する情報のつながりを見つける方法</h3> LogSeqには、知識のつながりを見つけるための様々な機能があります。 グラフビュー ページ間のつながりを視覚的に表示</li> 右上のグラフアイコンをクリック</li> ノードをクリックすると関連するページに移動</li> </ul> </li> 検索機能の活用 キーワードで関連ページを検索</li> タグとページリンクを組み合わせて検索</li> 日付範囲を指定して検索</li> </ul> </li> 知識のつながりを育てる方法 定期的にバックリンクを確認する</li> 関連しそうなページを積極的にリンクする</li> グラフビューで全体の構造を確認する</li> </ul> </li> </ul> このように、LogSeqでは知識同士を様々な方法でつなげることができます。つながりが増えるほど、新しい発見や気づきが生まれやすくなります。 まとめ</h2> 日常的な使い方のおすすめパターン</h3> LogSeqを効果的に活用するために、以下のような使い方がおすすめです。 1日の基本的な流れ 朝：今日やることを箇条書きで書き出す</li> 日中：思いついたことを [[]]</code> でリンクしながらメモ</li> 夜：その日の振り返りと、重要な項目に #タグ</code> をつける</li> </ul> </li> 知識を育てる方法 気になる言葉は積極的に [[]]</code> でリンク</li> 関連する過去のメモは右サイドバーのバックリンクで確認</li> 時々グラフビューを開いて知識の関係性を見直す</li> </ul> </li> 継続的な活用のコツ 完璧を目指さず、まずはメモを取ることから始める</li> 少しずつ機能を試して、自分に合う使い方を見つける</li> 定期的に過去のメモを見返して、知識をアップデート</li> </ul> </li> </ul> 困ったときの対処法</h3> LogSeqを使っていて困ったときは、以下の方法を試してみましょう。 書き方を忘れたとき Markdownの基本：#</code> で見出し、-</code> で箇条書き</li> リンクとタグ：[[ページ名]]</code> と #タグ名</code></li> これらは画面下部のヘルプアイコンでいつでも確認可能</li> </ul> </li> 情報が見つからないとき 検索バーに関連するキーワードを入力</li> タグで絞り込み検索</li> グラフビューで関連ページを探す</li> </ul> </li> 整理が必要と感じたとき 関連する情報を新しいページにまとめる</li> 適切なタグをつけて分類する</li> 不要になったメモは、アーカイブとしてタグ付け</li> </ul> </li> </ul> LogSeqは、使い始めは普通のメモ帳として、慣れてきたら知識を育てるツールとして活用できます。一度にすべての機能を使いこなす必要はありません。自分のペースで、少しずつ使い方を広げていってください。 Goodbye Bartender! 2024-11-12T00:00:00+00:00 Bartender</a> was menu bar wizard I'd been geeking out over. Turned out Ben Surtees had sold it to some shadowy outfit called Applause in March 2024. Reddit blew up with users freaking out. Today, I've now ditched Bartender for Ice,too. Keep it FOSS, keep it safe, am I right? バーテンダー</a>はメニューバーの魔術師で、私は熱中していました。ベン・サーティーズが2024年3月にApplauseという正体不明の会社に売却していたことが判明しました。Redditではユーザーたちが大騒ぎしていました。今日、私もバーテンダーを捨ててIceに乗り換えました。 オープンソースを守れば安全、そうでしょ？ Finaleがフィナーレを迎える 2024-08-27T00:00:00+00:00 採譜ソフトのFinaleが開発・販売を終了するそうです。 音楽はざっくり言うと作曲->アレンジ->採譜->演奏というプロセスが必要ですが、「採譜」というプロセスは現代では端折られることも多いし、何か新しい革新があるわけでもないから「incremental value for our customers」が無くなったというのは確かにそうなんだろうと思います。 ただ日本のクラシック音楽界隈ではデファクトスタンダードなどで、関係者には「Finaleがフィナーレを迎えた」などと冗談を言える雰囲気ではないくらい深刻なようです。 The music notation software Finale will be discontinued in terms of development and sales. In music, the general process involves: composition</li> arrangement</li> notation</li> performance</li> </ul> However, the notation process is often skipped in modern times, and since there hasn't been any significant innovation in this area, it's understandable. They feel there is "no incremental value for our customers" anymore. That said, Finale is the de facto standard in Japan's classical music community. So for those involved, it's not exactly a laughing matter where they can joke that "Finale has reached its finale." Today, Finale is no longer the future of the notation industry—a reality after 35 years, and I want to be candid about this. Instead of releasing new versions of Finale that would offer only marginal value to our users, we’ve made the decision to end its development. {" "} the finale blog -{" "} {" "} The End of Finale </a> </cite> </footer> </blockquote>

GoFデザインパターンは現代でも有用か(3) — 言語に吸収されたパターンと非推奨のSingleton

GoFデザインパターンは現代でも有用か(2) — Go言語で不要になったパターン

「クラス継承」の副作用への処方箋だったパターン</h2>

「参照セマンティクス」を補完するパターン</h2>

GoFデザインパターンは現代でも有用か(1) — OOPのパラダイムシフトとGoFの誕生

Mac環境のリフレッシュ

gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール

5つのクラシックUADプラグイン：黄金時代のスタジオレジェンド

The Plugins I Purchased</h2>

Sublime Text - 職人主義的ソフトウェアの美学と持続可能なビジネスモデル

1. 技術的・思想的特徴</h2>

Archetype: Cory Wong X

Neural DSP Archetypeプラグインを買おう

Archetype: Plini X</h3>
Archetype: Plini X</a>は、プログレッシブ、フュージョン、メタルのブレンドサウンドに特化した汎用性の高いプラグインです。</p>
アンプの前にディレイがあるのは魅力的ですね。</p>

Scaler3で作曲支援

まとめ</h2>
Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>

Synthersizer V Studio 2 Pro

Sythesizer V Studio 2 Proの変更点</h2>
次のような変更がなされています。</p>

textlintで日本語ブログの品質を向上させよう

インストールと設定</h2>

設定の詳細解説</h2>

ルール</h3>

ChromaLensCLI: Command Line Color Accessibility Validation

LogSeq at a Glance: An Overview for Beginners

はじめに</h2>

LogSeqの基本的な使い方</h2>

日々のノート作成の基本</h2>

知識のつながりを作る</h2>

まとめ</h2>

Goodbye Bartender!

Finaleがフィナーレを迎える

Coded Chords - Software

読了『闘うプログラマー』

GoFデザインパターンは現代でも有用か(4) — 現代でも有用なパターンとまとめ

Coded Chords - Software

読了『闘うプログラマー』

GoFデザインパターンは現代でも有用か(4) — 現代でも有用なパターンとまとめ

GoFデザインパターンは現代でも有用か(3) — 言語に吸収されたパターンと非推奨のSingleton

GoFデザインパターンは現代でも有用か(2) — Go言語で不要になったパターン

「クラス継承」の副作用への処方箋だったパターン</h2>

「参照セマンティクス」を補完するパターン</h2>

GoFデザインパターンは現代でも有用か(1) — OOPのパラダイムシフトとGoFの誕生

Mac環境のリフレッシュ

Mole — macOSクリーンアップツール</h2> </iframe> macOSのクリーンナップと最適化に特化したコマンドラインツールです。 CleanMyMac、AppCleaner、DaisyDisk、iStat Menusなどの機能を1コマンドでカバーしていると謳っています。</p>

メニューバーの整理</h2> MacBookでメニューバーにたくさんアイコンが並ぶと、ノッチの裏に隠れて見えなくなる問題があります。この対策としてメニュー表示管理ツールを使用していました。</p>

gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール

5つのクラシックUADプラグイン：黄金時代のスタジオレジェンド

The Plugins I Purchased</h2>

Sublime Text - 職人主義的ソフトウェアの美学と持続可能なビジネスモデル

1. 技術的・思想的特徴</h2>

1.1. 圧倒的なパフォーマンス</h3> 起動が非常に速い</li> 大規模ファイルや巨大リポジトリでも編集が軽快</li>

Archetype: Cory Wong X

Neural DSP Archetypeプラグインを買おう

Post Effect</h4> The 80s - 80年代風ヴィンテージコーラス</li> Delay-y-y - アナログ回路ベースのBBDディレイ</li>

Archetype: Plini X</h3> Archetype: Plini X</a>は、プログレッシブ、フュージョン、メタルのブレンドサウンドに特化した汎用性の高いプラグインです。</p> アンプの前にディレイがあるのは魅力的ですね。</p>

Scaler3で作曲支援

まとめ</h2> Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>

Synthersizer V Studio 2 Pro

Sythesizer V Studio 2 Proの変更点</h2> 次のような変更がなされています。</p>

textlintで日本語ブログの品質を向上させよう

インストールと設定</h2>

設定の詳細解説</h2>

ルール</h3>

ChromaLensCLI: Command Line Color Accessibility Validation

LogSeq at a Glance: An Overview for Beginners

はじめに</h2>

LogSeqの基本的な使い方</h2>

日々のノート作成の基本</h2>

知識のつながりを作る</h2>

Archetype: Plini X</h3>
Archetype: Plini X</a>は、プログレッシブ、フュージョン、メタルのブレンドサウンドに特化した汎用性の高いプラグインです。</p>
アンプの前にディレイがあるのは魅力的ですね。</p>

まとめ</h2>
Scaler3は「音楽理論の知識」と「直感的な操作」のバランスが絶妙なツールです。</p>

Sythesizer V Studio 2 Proの変更点</h2>
次のような変更がなされています。</p>