検索結果

2025年12月12日（金）12:00より、LPI日本支部主催のWebinar「WDE試験合格に重要 JavaScript/Node.js/データベース」を開催します。 本ウェビナーでは、堀 光 様が詳しく解説します。 今回は、LPI 認定試験 (Web Development Essentials)の合格に向けて Webシステム開発で使用されるJavaScriptやNode.js、データベースについて解説します。 クライアント側の動的処理やサーバー側での処理を、講義と実習を通して学習します。 クラウド上の仮想マシンによる演習も用意されているので、Webシステム開発をより実践的に学ぶことができます。 登録はこちらから!

2025年11月29日（土）11:00より、LPI日本支部主催のWebinar「＜改訂版＞【学生・初心者向け】Webエンジニアになろう～WDEを習得！④Node.js入門編〜」を開催します。 本ウェビナーでは、かわむら かな 様が詳しく解説します。 今回は、10月18日(土)に開催されたOSC Online/Fallで講演した Web開発エンジニアになるための初級講座、Node.jsとExpress編の内容をアップデートしてお届けいたします。 登録はこちらから!

このシリーズの前回の記事では、ウェブページをダイナミックにし、エンドユーザーとのインタラクションを可能にするフロントエンド・プログラミング言語、JavaScriptについてお話した。 JavaScriptは長年にわたってサーバーサイドの機能も拡張し、バックエンドのプログラミングに応用されてきた。 そこでNode.jsの出番となる。 バックエンドプログラミングのためのNode.js Node.jsは、JavaScriptで書かれたプログラムを実行することで、ウェブサーバーで受け取ったリクエストを処理できる実行環境だ。 Node.jsは、もともとクライアントサイド言語であったJavaScriptを、他のプログラミング言語と同じようにブラウザの外で実行できるようにした本格的な開発プラットフォームである。 本来はブラウザーの中だけで実行されるはずだった言語が、今ではブラウザーの外で実行されるのだ。 このことから、以下のような多くの利点が生まれる： 学習が容易： すでにJavaScriptに慣れ親しみ、クライアント側のプログラミングに取り組んできた開発者は、サーバー側のアプリケーションを開発するために別のプログラミング言語を学ぶ必要はない。 すでにJavaScriptをマスターしているフロントエンド開発者は、それほど苦労することなく、アプリケーションのバックエンド部分に簡単に取りかかることができる。 完全かつ機能的なアプリケーションを作成する能力： JavaScriptという1つのプログラミング言語の知識だけでも、クライアントサイドとサーバーサイドの両方の開発に精通したフルスタック開発者として働くことが可能です。 これにより、包括的で完全に機能するアプリケーションを作成することができる。 様々なアプリケーションを作成可能 JavaScriptコードを実行できる環境があれば、ウェブブラウザに依存しないスタンドアローンプログラムを作成することができます。 これにより、さまざまなタイプやシナリオのアプリケーションを作成する可能性が広がる。 しかし、なぜNode.jsはこれほどまでに開発者に愛されているのだろうか？ 前述の利点に加え、Node.jsはオープンソースでクロスプラットフォーム環境であり、世界中の開発者の大規模なコミュニティを誇っている。 さらに、非同期、ノンブロッキング、シングルスレッド、イベントドリブンI/Oモデルに基づいており、高いパフォーマンスと優れた実行速度を保証します。 クライアントからのリクエストを効率的に管理する。 Linux Professional Institute (LPI)のWeb Development Essentials認定資格は、このシリーズのコンテンツに特化しており、簡単なNode.jsアプリケーションの作成を段階的にガイドしています。 さらに、HTML、CSS、JavaScriptを使用してウェブページを作成したことがあれば、アプリケーションのバックエンドロジックの構築を開始し、特定のユーザーリクエストに対してサーバーがどのように応答すべきかを定義することができます。 アプリケーションの強化方法 Node.jsプロジェクトでは、他の開発者によって作成されたさまざまな無料のリソースやツールを利用して、追加機能を組み込んだり、生産性を向上させたり、作業を容易にしたりすることができます。 npmはNode Package Managerの略で、Node.jsプラットフォームのパッケージ・マネージャーです。 コマンドラインインターフェイスを通じて、パッケージ（他の開発者が作成した、特定の機能を実装するビルド済みのプロジェクト）のインストール、削除、管理を行うことができる。 npmはNode.jsパッケージの大規模なオンラインリポジトリで、それぞれが独自の機能を備えていると考えてください。 数え切れないほどあるパッケージの中には、データベースとのやりとりに特化したものもある。 この連載の第1回で述べたように、バックエンド・プログラミングは、データベースとの統合を含め、エンドユーザーから直接見えないすべての側面を包含する。 アプリケーションが外部データにアクセスする必要がある場合、ほとんどの場合データベースを通じてアクセスすることになる。 LPIのWeb Development Essentialsでは、リレーショナルデータベース管理システム（RDBMS）を実装したソフトウェアライブラリであるSQLiteを特に取り上げています。 このタイプのデータベースでは、データは相互に接続されたテーブルに格納され、シンプルで直感的なクエリを使って照会することができる。 データベース照会 リレーショナル・データベースを自由に使えるようになったとき、そのデータベースに対してどのような操作を行なえばよいのか悩むかもしれない。SQLはStructured Query Languageの略で、リレーショナルデータベース内のデータを操作するためのクエリ言語です。 非常に人気があり、ユーザーフレンドリーな言語である： テーブルの作成と削除 スキーマと呼ばれる、各テーブルで使用可能なフィールドとデータタイプを定義する。 テーブルのデータを更新する テーブルの行の挿入と削除 情報の取得 データベースの保守と最適化 これで、リレーショナル・データベースがSQLデータベースとも呼ばれる理由が明らかになった！ 開発者がSQLを使うのは、SQLがさまざまなプログラミング言語と非常にうまく統合できるからだ。 例えば、Node.jsでSQLiteを使うには、先に述べたnpmパッケージ・マネージャーを使ってモジュールをインストールするだけでよい。 これをインストールすると、リレーショナル・データベースの作成と保守を可能にする一連の関数にアクセスできるようになる。 関連するテーブルに情報を格納するリレーショナル・データベースに加え、NoSQLデータベースとも呼ばれる非リレーショナル・データベースもある。 これらはより柔軟なスキーマを持ち、バックエンドアプリケーションでも同様に使用できる。 非リレーショナル・データベースは、特定のアプリケーションと格納されるデータに最適化されたストレージモデルを使用する（例えば、情報は単純なキーと値のペアとして格納できる）。 この種のデータベースは、開発が容易で高性能、優れた柔軟性と拡張性が特徴である。 以下の表は、バックエンドアプリケーションで一般的に使用される、最も一般的なリレーショナルデータベースと非リレーショナルデータベースの一覧です： SQL Database NoSQL Database Microsoft SQL Server MongoDB SQLite CouchDB MySQL Redis MariaDB PostgreSQL   SQL言語とSQLiteデータベースに慣れたら、練習がてら非リレーショナル・データベースでデータを操作し、その長所と短所を発見してみよう。 次はどうする？ 今回と前回の連載では、WDE認定資格でカバーされる主な技術（HTML、CSS、JavaScript、Node.js、SQL）と、Web開発者としての第一歩を踏み出すためのプログラミング環境について分析してきました。 まだ解明されていないのは、どの学習リソースが実際の認定試験に最も適した準備ができるかということだ。 これからの連載では、Web [...]

長年、「仮想マシンはコンテナに置き換えられるのか？」という議論が続いていました。しかし現在では、答えは少し違ったものになっているようです。なぜなら、その間にそもそもの問い自体が変わったからです。つまり、「2つの技術がもはや競合するのではなく、協調して使われているのであれば、置き換えること自体に意味があるのか？」ということです。 この10年ほどの間に、「コンテナが仮想マシンに取って代わる」というイノベーションへの期待に基づく、ある意味で理念的な対立から、より現実的なアプローチへと変化してきました。現在では、Kubernetesのインスタンスが仮想環境の中で実行されることも多く、クラウドプロバイダーは複数の技術レイヤーを組み合わせて、プラットフォーム全体を構築しています。 一見すると、この2つの技術は似ており、同じような結果をもたらすように見えるかもしれません。しかし、それぞれの違いを深く理解することで、それぞれが持つ固有の強みが見えてきます。 2種類のハイパーバイザー 仮想環境（仮想マシンだけに限りません）について説明する際には、仮想マシンを実行するハイパーバイザーの種類について区別する必要があります。 タイプ1のハイパーバイザーは、ベアメタル上でリソースを管理するソフトウェアとして直接動作し、仮想インスタンスからメモリ、プロセッサー、ネットワークインターフェースなどのハードウェアリソースへ直接アクセスできるようにします。XenとKVMは、タイプ1のハイパーバイザーの代表的な例です。KVMは、複雑で体系的なエンタープライズ環境に適した仮想化プラットフォームであるProxmox VEの基盤でもあります。Proxmox VEは、負荷分散、クラスタ管理、高可用性に対応しています。 もう1つがタイプ2のハイパーバイザーです。こちらは、オペレーティングシステム上でプログラムとして動作する、追加のレイヤーの上に構築されます。代表的なものとして、VirtualBoxやVirt-Managerがあります。 図1では、タイプ1とタイプ2のハイパーバイザーの違いを比較しています。 図1：ハイパーバイザーの種類による主な違い。 リソースの使用効率や管理のしやすさという点では、タイプ1のハイパーバイザーが圧倒的に優れています。そのため、業務環境では広く利用されています。一方、より多くのリソースを必要とするタイプ2のハイパーバイザーは、複雑で高負荷なワークロードを任されることはほとんどありません。 コンテナ：軽量さを追求して生まれた技術 コンテナは、「軽量であること」を大きな特徴として生まれました。仮想マシンとは異なり、ハードウェアシステム全体を仮想的に再現する必要も、インスタンスごとに完全なオペレーティングシステムを起動する必要もありません。コンテナ内のプロセスは、ホストシステムのカーネルを共有しながら、それぞれ分離された状態で動作します。 この分離を可能にしているのが、Linuxカーネルの機能です。Namespace（名前空間）は、プロセス、ネットワーク、ファイルシステム、ユーザーなどの要素を分離し、それぞれのコンテナからは、あたかも独立した環境であるかのように見える状態を作ります。Control Groups（コントロールグループ、一般にcgroupsと呼ばれます）は、メモリ、CPU、入出力などのリソース使用量を制御・制限することを可能にします。 その結果、従来の仮想マシンよりもはるかに軽量な環境が実現します。コンテナは専用のカーネルを必要としないため、短時間で起動でき、必要なストレージ容量やメモリも少なくて済みます。これにより、同じホスト上で多数のコンテナを実行し、非常に短時間でデプロイすることが可能になります。 ただし、コンテナを小さな仮想マシンと考えてはいけません。コンテナは、まず第一に、アプリケーションを実行するために必要なライブラリや依存関係とともに、分離されたプロセスの集合です。そのため、コンテナの分離レベルは、ホストシステムと共有しているカーネルに依存します。一方、仮想マシンは独自のカーネルと独立したオペレーティングシステムを持っています。 また、コンテナイメージも重要な役割を果たします。コンテナイメージには、アプリケーション、その依存関係、そして再現可能な環境を構築するために必要な設定が含まれています。同じイメージを開発環境、テスト環境、そして最終的な本番環境で実行できるため、環境間の違いを減らすことができます。Dockerは、このモデルの普及に決定的な役割を果たしましたが、コンテナという概念は特定の1つの製品に限定されるものではありません。現在のエコシステムには、Podman、containerd、CRI-Oなどのツールに加え、Open Container Initiative（OCI）が推進する共通規格も含まれています。そしてKubernetesは、コンテナそのものを直接作成するのではなく、1つまたは複数のノードにまたがってコンテナの実行、分散、可用性を管理します。 コンテナの軽量な構造は、仮想マシンを自動的に置き換えることを意味するわけではありません。カーネルを共有することでリソース消費量を抑えられる一方、分離のレベルも異なり、場合によっては十分ではありません。まさにこの点から、仮想マシンとコンテナの「競争」は、次第に「相互補完」へと変わっていきます。仮想マシンはインフラをより明確に分離できる一方、コンテナはアプリケーションのデプロイをより簡単かつ迅速にします。 図2では、仮想マシンとコンテナの構成要素をまとめています。 図2：仮想化技術とコンテナ技術の簡単な技術比較。 両者が融合する場所 融合の具体例として、複数のLinux仮想マシンを実行する仮想化クラスタを考えてみましょう。そのうちの一部はKubernetesクラスタのノードとして利用し、その他はデータベース、レガシーシステム、あるいはより強固な分離が必要なサービス専用として利用することができます。Kubernetesに割り当てられた仮想マシンの中では、コンテナランタイムがアプリケーションコンテナを実行し、それらはPodとしてまとめられ、各ノードに分散されます。ハイパーバイザーは物理リソース、分離、高可用性を管理し、Kubernetesはコンテナ化されたアプリケーションのライフサイクル、分散、スケーリングを管理します。 このアーキテクチャでは、仮想マシンとコンテナは同じ役割を奪い合っているわけではありません。それぞれ異なるレイヤーで動作しています。仮想マシンはインフラの境界を定義し、コンテナはアプリケーションを分散・実行する単位を定義します。図3は、この複合的なアーキテクチャを示しています。 図3：仮想化技術とコンテナ技術を統合したアーキテクチャの例。 まさにこの点で、仮想マシンとコンテナの競争という考え方は意味を失います。現代のインフラでは、コンテナは仮想マシンを置き換えるものではありません。多くの場合、コンテナは仮想マシンの中で動作しています。仮想マシンはインフラを分離し、コンテナはアプリケーションの分散と実行を担います。つまり、同じアーキテクチャの中にある、異なる役割を持つ補完的な2つのレイヤーなのです。 これらのテーマを体系的に学ぶには、LPIC-3 Virtualization and Containerization認定が有用な学習手段となります。この認定では、KVM、Xen、libvirt、Linuxコンテナ、Docker、Podman、Kubernetes、および仮想化環境の管理・オーケストレーションに用いられる主要な技術について、知識を体系的に身につけることができます。 << このシリーズの前の記事を読む | シリーズを最初から読む >>

2002年、権威ある『Yale Law Journal（イェール・ロー・ジャーナル）』に、目を引くタイトルの論文が掲載されました。当時、学術界や政府、企業では、政策や製品に関する意見を、資格や肩書きを持つ専門家だけでなく、一般の人々からも取り入れるという、刺激的で、社会をより自由にする可能性を秘めた考え方が模索されていました。 この考え方をさらに推し進めたのが、ハーバード・ロースクールの法学教授である Yochai Benkler です。Benkler教授は、『Yale Law Journal』に「Coase’s Penguin, or, Linux and The Nature of the Firm（コースのペンギン、あるいはLinuxと企業の本質）」というタイトルの論文を発表しました。 では、なぜLinuxが、著名な法学教授の研究対象になったのでしょうか。なぜBenkler教授は、Linuxを「より広範な社会経済現象」の一つの事例として取り上げ、それが何世紀にもわたって続いてきた企業や政府の行動様式を覆す可能性があると考えたのでしょうか。 Benkler教授だけが、Linuxを一つの原則や象徴として高く評価したわけではありません。このシリーズでは、2021年に公開した私の記事をもとに内容を更新し、1990年代初頭に登場して以来、Linuxが持つようになったさまざまな意味について探っていきます。Linuxが次のような形で歴史を変えてきたことを解説します。 完全に自由なコンピューターシステムの基盤を提供した フリーソフトウェアおよびオープンソースソフトウェアが実用に耐えることを、あらゆる分野の人々に示した 企業が、自社ソフトウェアの中核部分について、オープン標準やオープンソースによる実装へ移行するきっかけを作った 現代的なソフトウェアを、より多くの人々が利用できるようにした 仮想化、コンテナ、クラウドによってコンピューター業界を再構築した 当時新たに認識され始めていた「クラウドソーシング」という現象への関心を呼び起こした 研究に利用できる大規模なデータソースを提供した 新しい低価格ハードウェアプラットフォームの開発と普及を加速させた 今回の記事では、このリストの最初の2つについて取り上げます。 自由なOSの基盤 コンピューティングの黎明期から、自由に利用できるソフトウェアは公開されてきました。しかし、ユーザーのニーズを包括的に把握し、その幅広いニーズに応えることに取り組んだプロジェクトは、ほとんどありませんでした。 初期のフリーソフトウェア開発者の多くは、ベンダーが提供するコンピューターシステム上で動作するライブラリやツールを提供することに満足していました。その中でも、最も壮大なビジョンを持っていた初期のフリーソフトウェアプロジェクトが、Berkeley Software Distribution（BSD）です。 BSDは、Bell Labsが開発した自由に利用できないUnixに改良を加えることから始まり、その後、幅広い目的を持つ独立したプロジェクトへと発展しました。BSDの派生版は多くのコンピューター企業で重要な役割を果たしましたが、Microsoft、そして後のAppleと比較すると、BSDはニッチな存在にとどまりました。 GNUプロジェクトは、さらにニッチな存在でした。GNUもまた壮大な目標を掲げていました。開発者たちは、Unixをゼロから再構築するため、次々とツールを体系的に開発していきました。 これらのツールはすべて開発者にとって重要なものでした。特に、優れたコンパイラーやC/C++ライブラリは非常に重要でした。しかし、一般的なコンピューターユーザーにとって興味を引くものはほとんどありませんでした。GNUCash会計ソフトウェアのようなエンドユーザー向けプロジェクトは少なく、しかも使いこなすのは容易ではありませんでした。 GNUツールの最大の特徴はGNUライセンスにありました。このライセンスによって、誰もが自由に利用・共有できることが保証されていたのです。 そのライセンス、品質、あるいはCプログラマーによる幅広い利用のいずれかが理由だったのかもしれませんが、Linus TorvaldsはGNUのツールを使ってLinuxを開発しました。そしてLinuxの重要性が高まるにつれて、GNUの重要性も高まっていきました。 GNUとLinuxの発展は切り離して考えることができません。そのため私は、GNUの支持者たちと同じく、OSの完全なディストリビューションは「GNU/Linux」と呼ぶべきだと考えています。ただし、このシリーズでは便宜上、Linuxという言葉を広い意味で使用します。 では、完全に自由なソフトウェアによるスタックが、一般の人々にとって何を意味したのでしょうか。 それは、特に組み込みシステム、小規模なインターネットサービスプロバイダーやその他のインターネットサービス、そして世界中の十分なコンピューティング環境を利用できていない人々のための低価格コンピューターといった分野で、さまざまな実験や取り組みが爆発的に増えることにつながりました。 自由なソフトウェアスタックは、企業のデータセンターにもさらに大きな影響をもたらしました。これらの現象については、このシリーズの後半で詳しく取り上げます。 完全に自由なGNU/Linuxスタックを利用する場合でも、ユーザーは依然としてプロプライエタリなコンピューターとプロプライエタリなファームウェアを必要としていました。しかし、やがてこの2つの問題も解決されていきました。 成長を続けるオープンハードウェアの取り組みによって、オープンな設計を配布・カスタマイズできるようになっています。このテーマについては、別の記事でも取り上げています。また、自由に利用できるファームウェアのプロジェクトも数多く存在します。 フリーソフトウェア／オープンソースソフトウェアの実用性を証明 1990年代まで、ビジネスの世界ではほとんど議論の余地がありませんでした。ソフトウェアによってアイデアを実現するには、会社を設立し、専門家のチームを雇って製品を開発する必要がある、と考えられていたのです。 当時は、要件定義から開発、テスト、そして本番環境への移行までをチームが順番に進めていくウォーターフォールモデルが、ほぼ一般的な開発手法でした。 1990年代後半に起こったドットコム・ブーム（投資家の過剰な熱狂によって生まれたバブル）が起こるまでは、会計部門やマーケティング部門が、そのソフトウェアからどのように利益を上げるのかを明確にできなければ、ソフトウェアプロジェクトそのものが始動することはありませんでした。 フリーソフトウェアは、まるで別の世界で進んでいるかのように見えました。資金力や組織的な影響力を持つ人々は、フリーソフトウェアを真剣に受け止めていなかったのです。 もちろん、MicrosoftやAT&Tなどの企業は、BSDの革新的な技術を自社のプロプライエタリなソフトウェアに取り入れていました。また1980年代半ばには、GNU C/C++コンパイラーが商用コンパイラーを上回る性能を発揮し、開発者たちを驚かせました。 これらの個別の出来事は、フリーソフトウェアで何か大きなことが起きていることを示す兆候でした。しかし、技術的に専門性が高く、政策決定者からは見過ごされていました。 最終的に、Linuxが経営幹部レベルの固定観念を打ち破ることになりました。 企業は、フリーソフトウェアがもたらす継続的なメリットを理解するようになりました。こうした企業は、フリーソフトウェアに依存することに慣れ、それが堅牢で信頼できるものだと分かるようになると、自社のソフトウェアもオープンにすることに前向きになります。 その頃には、フリーソフトウェアを理解し、愛着を持つ開発者を社内に数多く抱えている可能性もあります。そして、そうした開発者たちが企業に対して、フリーソフトウェアへの貢献を促すようになります。 この物語の続きについては、シリーズの次回の記事で詳しく紹介します。

オープンハードウェアへの長い道のり：ARMSoMとRockchipを試す プロセッサーからファームウェアに至るまで、すべてのコンポーネントが完全にオープンで、誰でも自由に利用できる「真のオープンハードウェア」は、いまだ実現が難しい目標です。 最近、RockchipのSystem-on-Chip（SoC）プロセッサーを搭載したARMSoM（Banana Pi）のシングルボードコンピューター（SBC）を2種類テストしました。これらのボードは、AIアクセラレーション、IoT接続、組み込みLinuxへの対応をうたっています。 しかし、本当によりオープンなコンピューティング環境への進歩を示しているのでしょうか。 この記事では、これらのボードが提供する機能、オープンハードウェアが依然として発展途上にある理由、そして私たちが今後克服すべき課題について考察します。 テストした製品は？ ハードウェアの概要 今回テストした2つのボードは、どちらもRockchipのSoCを搭載しています。 ARMSoM Sige5：Rockchip RK3576 SoC、Neural Processing Unit（NPU）、デュアルGigabit Ethernet、Wi-Fi 6、拡張ストレージ用のM.2スロットを搭載しています。 ARMSoM P2Pro：SBCとマイクロコントローラーの中間に位置するボードで、IoT、オートメーション、産業用途を想定して設計されています。Power over Ethernet（PoE）に対応し、非常に低い消費電力を実現しています。 どちらも非常に高い性能を備えています。しかし、本当に重要なのは「どの程度オープンなのか」という点です。 Rockchipとオープンハードウェアのジレンマ Rockchipは、Linuxコミュニティでも比較的よく知られているSoCメーカーの一つです。多くの競合メーカーと比較すると、少なくともLinux用のドライバーを提供している点は評価できます。 しかし、ここには問題があります。 これらのドライバーは、古いベンダー固有のLinuxカーネルのフォークをベースにしています。 そのままmainline Linuxに組み込めるようには設計されていません。mainline Linuxに対応させる作業はボランティアに委ねられており、コードの大部分を書き直さなければなりません。 つまり、これらのチップで長期的かつ適切にサポートされたLinux環境を実現するのは、非常に困難な道のりになります。 Collaboraのような組織の支援を受けたコミュニティ主導のプロジェクトは、RockchipのドライバーをLinuxのmainlineへ統合するために懸命に取り組んでいます。しかし、その作業は時間がかかり、難しく、しかも一貫性を保つのが容易ではありません。 オープンハードウェアへの長い道のり これはRockchipだけの問題ではありません。業界全体が抱える、より大きな問題の一つの表れです。 ARMベースのSBCやその他の組み込み機器が真にオープンになるためには、次のような大きな障壁があります。 不透明なサプライチェーン：ブートローダーやファームウェアなど、多くの重要なコンポーネントが依然としてプロプライエタリです。 短いベンダーサポート期間：メーカーは、持続可能なソフトウェア開発よりも、製品の短期間での世代交代を優先することが少なくありません。 真にオープンなSoCの不足：RISC-Vのようなプロジェクトには期待が寄せられていますが、現在の状況を変えるには、まだ初期段階にあります。 Rockchipは一部の競合メーカーよりもオープンな姿勢を見せています。しかし、業界全体として見ると、オープンハードウェアが現実のものになるまでには、まだ長い道のりがあります。 ARMSoM Sige5をテスト：AIアクセラレーション、その代償 Sige5の大きなセールスポイントの一つが、専用NPUによるAI機能です。最大6 TOPS（Trillions of Operations Per Second、1秒あたり数兆回の演算）の処理性能をうたっています。 しかし、よくあることですが、実際の性能はマーケティング上の説明と完全には一致しませんでした。 動作するもの MobileNet、ResNet、YOLOv5など、事前に最適化されたモデルを実行する場合、AI推論速度は十分に優れています。 NPUは電力効率に優れており、同じ処理をCPUやGPUで実行する場合と比べて、はるかに少ない電力で済みます。 問題点 mainline Linuxに対応していないため、ベンダーが保守するDebianまたはAndroidのイメージを使用せざるを得ません。 新しいファームウェアを書き込むにはプロプライエタリなツールが必要です。その一部はWindowsでしか利用できず、初期状態では中国語で表示されます。 エコシステムが分断されているため、より広範なAI開発ワークフローにこのボードを統合するのが困難です。 可能性は十分にあります。しかし、ソフトウェアとの統合が改善されない限り、実際の利用環境における使いやすさには限界があります。 ARMSoM P2Proをテスト：高い能力を備える一方、中途半端な立ち位置 P2Proは、SBCとマイクロコントローラーを組み合わせた興味深い製品で、IoTやオートメーション向けの仕様になっています。 Power over Ethernet（PoE）、Wi-Fi 6、Bluetooth 5.0に対応しており、このボードが産業用途やネットワーク接続された環境向けに設計されていることは明らかです。 しかし、電力効率に優れている一方で、RAMがわずか512MBしかないため、Linuxをフルに動作させるような処理では苦戦します。 また、リアルタイムオペレーティングシステム（RTOS）にも対応していません。そのため、組み込み開発における選択肢としての魅力も低くなっています。 強力なソフトウェアサポートや明確な開発エコシステムがない現状では、P2Proは扱いの難しい中間的な位置にあります。堅牢なSBCでもなければ、シンプルで使いやすいマイクロコントローラープラットフォームでもありません。 それでも、より充実したドキュメントとmainline Linuxへの対応が実現すれば、P2Proはエッジコンピューティングやスマートオートメーションの分野で独自の地位を築ける可能性があります。 より大きな問題：オープンハードウェアには依然として大きな課題がある RockchipとARMSoMをめぐる問題は、さらに大きな問題を浮き彫りにしています。 オープンソースソフトウェアは大きく進歩してきましたが、ハードウェアの自由という点では、まだ大きく遅れています。 特に大きな課題として、次のようなものがあります。 クローズドソースのファームウェアとドライバー： 多くの重要なコンポーネントが、依然としてコミュニティからアクセスできない状態にあります。 短いベンダーサポート期間： 適切な長期サポートがなければ、デバイスはすぐに時代遅れになってしまいます。 高い開発コスト： オープンハードウェアの代替製品は開発コストが高く、普及させるのも容易ではありません。 オープンハードウェアの代替手段はどこにあるのか？ RISC-VやLibre-SOCのような取り組みは、業界に変化をもたらそうとしています。しかし、これらもまだ初期段階にあります。 現状は次のとおりです。 「オープンハードウェア」の大部分は、部分的にしかオープンではありません。 コミュニティ主導のプロジェクトには、大手メーカーと競争するための資金が不足しています。 Open [...]

誤った出発 この2回シリーズの前編では、長く使われ続けてきたプログラミング言語について取り上げました。今回は、将来を大きく期待されながらも、あまりうまくいかなかったいくつかの言語について見ていきます。 誤った出発 大きな注目を集めながらも、実際には広く普及しなかった言語があります。その代表的な例がPascalです。Pascalは、スパゲッティコードの問題を解決するために、著名なコンピューター科学者Niklaus Wirthによって1970年に開発されました。 Wirthをはじめ、当時の優れた研究者で、率直な物言いで知られ、ときには恐れられることさえあったEdsger W. Dijkstraなどは、プログラムのバグを減らし、保守性を高めるには「構造化プログラミング」が必要だと考えました。 親や地域社会が子どもに一定の秩序や環境を与えることで、子どもが（ときには）責任ある大人へと成長するように、優れたプログラミング習慣を強制する言語を使えば、責任あるプログラマーを育てられるという考え方です。 これは実際に優れたアイデアであり、「デザインパターン」という概念の初期の実例でもありました。デザインパターンという言葉はもともと建築分野の概念で、Christopher Alexanderが1977年の著書『A Pattern Language: Towns, Buildings, Construction』で提唱したものです。その後、この言葉は、一般に「Gang of Four（GoF）」として知られる4人のコンピューター科学者の専門家による1994年の著書『Design Patterns: Elements of Reusable Object-Oriented Software』によって、プログラミングの世界にも取り入れられました。 実際には、デザインパターンは、まずプログラマーが守るべき優れたプログラミング手法として始まります。しかし、実際にそれを実践するのは難しいものです。そこで、そうしたパターンはライブラリに組み込まれ、使いやすくなります。そして最終的にはプログラミング言語の構文にまで統合され、プログラマーは抽象的なレベルで深く考えなくても、forallのような便利な構文を使えるようになります。 Pascalはコンピューター科学の研究者たちから高く評価され、正しいプログラミング方法を誰にでも示す言語になると期待されました。Pascalは現在のJavaと同じように、コンピューターサイエンスの授業で広く教えられており、これが決定的な普及につながるはずでした。 では、なぜPascalは生き残れなかったのでしょうか。 どうやら、あの優れたWirthでさえ、優れたプログラミング手法を標準化するには十分なところまで踏み込めず、プログラミングの世界がどちらへ向かおうとしているのかを見極められていなかったようです。 Pascalはオブジェクト指向に対応していませんでした。当時、オブジェクト指向という概念はすでに普及し始めていました。Object Pascalは1980年代半ばに登場しましたが、時すでに遅しでした。 開発者のJames Vasileは、Pascalの問題は教育用言語として設計されたことにあると指摘しています。Pascalには移植性のあるコンパイラーがなく、可変長文字列型など、実際の製品開発に必要な機能も不足していました。こうした問題のいくつかは、コンピューター科学研究者のGreg Wilsonがこの記事をレビューした際に引用した論文、『Why Pascal Is Not My Favorite Language』でも指摘されています。この論文の著者Brian Kernighanは、UnixとCの主要な開発者の一人です。 もう一つ、期待されたものの普及しなかった興味深い言語がObjective-Cです。Objective-CはC++の登場から間もなく開発されました。 Objective-Cが注目される理由は、構文が複雑で、イントロスペクション機能を備え、メモリ管理システムも分かりにくい言語だったにもかかわらず、Steve JobsがAppleを離れた後に開発した新しいコンピューター「NeXT」で採用したことにあります。これは1980年代のことで、C言語をベースとしたオブジェクト指向言語のうち、どれが主流になるのかがまだ明確ではなかった時代でした。 そして1997年、現在の巨大企業Appleへと変貌させるためにJobsがAppleへ復帰すると、Jobsは、それまでにもっと良い選択肢があることを知っていたはずなのに、アプリケーションをObjective-Cで開発するよう求めました。iPhoneで伝説的な「App Store」が開設され、開発者たちがアプリを作れるようになったとき、彼らは皆Objective-Cを学ばなければなりませんでした。 現在、Appleはモバイル端末向けにSwiftを使用しているため、Objective-Cは本来の「目立たない言語」へと戻りつつあります。 Googleもモバイル端末向けの開発で同様の進化をたどりました。最初は広く普及していたJavaを推奨していましたが、その後、当時はあまり知られていなかったKotlinへと移行しました。 大規模な組織が支持し、開発者に導入を強く促した言語がほかにも2つあります。 1つ目はPL/Iです。PL/Iは、巨大組織という言葉だけではその圧倒的な存在感を十分に表現できないほどの大企業であるIBMによって、1960年代に推奨されました。PL/Iは、プログラミング言語界の「Edsel」になってしまいました。 もう1つはAdaです。Adaは1970年代に米国国防総省（DoD）によって開発され、数多くの国防関連契約で使用が義務付けられていました。DoDはインターネットを支援したときには正しい判断をしましたが、Adaでは大きくつまずくことになりました。Vasileは、Adaには高価なプロプライエタリコンパイラーも必要だったと指摘しています。 ここで、多くの人、特にRubyの支持者にとっては議論を呼ぶ主張を取り上げましょう。 RubyはPascalやPerlのような道をたどったわけではありません。しかし、Ruby on Railsが登場した2000年代半ばの絶頂期と比べると、現在のRubyは大きく勢いを失っています。当時のRubyはPerlの後継言語のように見え、実際にPythonを大きく上回っていました。 RubyがPerlやPythonほど広く普及しなかったのは、Rubyの開発者が日本人で、北米のコミュニティの外側にいたからだという人もいます。しかし、RailsはRubyにとって非常に大きな普及のきっかけとなりました。 私の考えでは、Railsは当初思われていたほどの価値を発揮しませんでした。そしてRailsへの熱狂が冷めると、RubyはPythonほど多くの魅力を提供できなくなりました。 Railsは、動的なWebページを提供するサーバー側プログラムをテンプレートベースで開発するための、初期のフレームワークでした。プログラマーが非常に短時間で実装を進められる基本設計を提供していました。 しかし同時に、Railsの設計者であるDavid Heinemeier Hansson（DHH）の前提や考え方を、そのまま固定化してしまう側面もありました。DHHのWebページとまったく同じように動作するWebページを作りたいのであれば、Railsは素晴らしい選択肢です。しかし、DHHの想定する設計思想から離れるほど、その有用性は急速に低下します。 一方、Railsの初期の成功は、別の言語を好む開発者たちに、同様のフレームワークを開発するきっかけを与えました。その結果、やがて、考えられるほぼすべての現代的なプログラミング言語に、サーバーサイドWebアプリケーション向けのフレームワークが登場しました。 現在、最も人気があるもの（明確な統計は見つけられませんでした）は、JavaScriptのフレームワークであるNode.jsのようです。Node.jsは、アプリケーションのクライアント側とサーバー側で同じ言語を使えるようにすることで、開発上の障壁を減らします。さらに、一部の専門家は、パフォーマンスやその他の特性においてNode.jsのほうがRailsより優れていると評価しています。 Railsは現在も広く使われていますが、初期の数年間に得た勢いは失われています。その過程で、Rubyそのものも輝きを失いました。現在もRubyとRailsには一定の支持者がいますが、20年ほど前のような勢いはありません。 Rubyより前にはTcl（「ティクル」と発音）という言語があり、短期間ではありましたが、手軽で雑多なスクリプトを書くための言語としてPerlに取って代わる可能性がありました。 私が思うに、Tclで書かれた最も有名なプログラムは、Don LibesによるExpectです。これは、プロンプトからの入力を要求するシステムとの対話が必要なタスクを自動化するための、非常に便利なツールでした。 しかし最終的に、Tclの設計では複雑なプログラミング上の要求に対応するのが難しいことが分かり、現在ではかつての利用者からもほとんど思い出されない存在になっています。 勝ち残るために必要なこと このシリーズで紹介してきた、やや主観的で非常に個人的な意見を含む歴史から分かるのは、時間の経過とともにどの言語がプログラマーの心をつかみ、支持を得るのかを予測することは極めて難しいということです。 Javaの場合、その普及には当時の大手企業であるSun Microsystemsからの支援が決定的な役割を果たしました。しかし、IBM、Microsoft、Apple、さらには強大な米国国防総省までが自分たちの推す言語を普及させようとした取り組みは、ほとんど影響を及ぼしませんでした。 また、一流の研究者によって開発されたからといって、人気が出るとは限りません。Pascalがその例であり、MLやHaskellのような研究主導型の言語にも同様の事情があります。 一方、JavaScript、PHP、Pythonは、比較的荒削りな状態で始まりながらも、当初のニーズを十分に満たし、さらに発展する余地を残していました。その結果、より堅牢な言語へと進化していきました。 広く支持されることはなくても、より人気のある別の言語に強い影響を与える言語もあります。これについては、最近の記事「Functional Languages and the Future of Programming（関数型言語とプログラミングの未来）」で取り上げました。 Haskell開発チームのリーダーであるSimon Peyton Jonesは、次のように述べています。 「採用状況という観点から見た言語の成功は、技術的な優位性――洗練された設計、正式な仕様、さらにはプログラマーの生産性――との関連性が非常に弱い。技術とは関係のない問題や、社会経済的・技術的な問題が大きな影響を及ぼしている。」 つまり、私が思うに、プログラミング言語の開発者は非常に優秀な人々です。さまざまなプログラミング言語の設計や構築について学んだ人であれば、数学的に厳密なものを作り出すことができます。 しかし、それが美しく、実用的なアプリケーションのニーズを満たすかどうかという問題は、より複雑です。そして、その答えが分かるのは、おそらく時間が経ってからでしょう。 だからこそ、新しいプログラミング言語の開発が終わることはありません。もちろん、私たちがプログラミングそのものをやめ、すべてのコンピューティングをAIに任せるようになれば話は別です。しかし、それは人類の未来に対する人間自身の意思決定権を手放すことを意味します。そのような未来を、私たちの多くは受け入れないでしょう。 <<前回の記事を読む 

好奇心から始まったITとFOSSへの道：Konstantinos Giannakakisの歩み こんにちは。Konstantinos Giannakakisです。ここでは、私がITとFOSS（Free and Open Source Software：フリーおよびオープンソースソフトウェア）の世界へ進んだ道のりをご紹介します。 大学に初めて入学した当時、コンピューターサイエンスは私の専攻分野でも、将来のキャリアプランの一部でもありませんでした。私はITとは無関係の分野で学位取得を目指していましたが、間もなくコンピューターが非常に価値のある学習分野であることに気付きました。 私は、経済を動かす仕組みとコンピューターシステムを支える論理構造には共通点があると考えるようになりました。この気付きが、私にとってテクノロジーへの本格的な関心を持つきっかけとなりました。 最初の学位を取得した後、私はコンピューターサイエンスを学ぶ大学へ再び進学し、第二学位の取得を目指しました。そして、デジタルエコシステムが表面的には見えない部分でどのように動作しているのかを理解することを決意しました。 私がLinuxの世界に入るきっかけとなったのは、教科書ではなく、コミュニティでした。 Greek Association of Free Software / Open Source Software Users (GreekLUG)を通じて、地域のミーティングやオンラインでの交流に参加し、オープン性と協力関係によって結ばれた活気ある人々のネットワークを知りました。 このコミュニティは、オープンソースの理念を私に紹介してくれました。それは「知識やツールは自由に共有されるべきであり、それによって誰もが成長できる」という考え方です。 この考え方は、後に私のプロフェッショナルとしてのアイデンティティを形成する基盤となりました。 学生時代、私は趣味としてLinuxディストリビューションを試し始めました。 最初は単なる好奇心から始まった取り組みでしたが、次第にシステム管理や自動化への本格的な情熱へと発展していきました。 余っていたハードウェアを利用して初めて構築したホームラボは、私の日々のプロジェクトになりました。サーバーの構築、仮想マシンの作成、そして自宅の環境で実際に発生する問題のトラブルシューティングに取り組みました。 学習に体系性と深みを持たせるため、私はFOSS関連の認定資格取得にも取り組みました。 GreekLUGのメンバーとして活動する中で、Linux Professional Institute（LPI）のLPIC-1およびLPIC-2認定資格に合格するために必要な情報や指導を得ることができました。 これらの試験対策を通じて、単に技術知識を広げるだけではなく、Linuxをより深いレベルで理解する力も身につきました。 具体的には、ネットワーク、セキュリティ、システムプロセスなど、Linuxシステムを支える重要な分野について理解を深めることができました。 認定資格は、単なる資格証明以上の大きな価値をもたらしてくれました。 それらは、堅牢なシステムを構築・維持するための自信を与えてくれ、独学で行っていた実験的な取り組みを、プロフェッショナルレベルのスキルへと発展させる助けとなりました。 こうして身につけた能力は、初めてのIT職への扉を開き、さらに現在の、成長を続けるテクノロジー企業でDevOpsエンジニアとして働く道へとつながりました。 現在、私はCI/CDパイプラインの設計・管理、クラウドインフラストラクチャの運用、分散環境におけるシステムの安定稼働などに取り組んでいます。 これらの業務には、オープンソースの世界から学んだ原則が息づいています。それは、透明性、協力、そして継続的な改善という価値観です。 仕事以外でも、私は現在もオープンソースコミュニティへの貢献を続けています。 これまでに、ソフトウェアドキュメントのギリシャ語翻訳、オープンソースプロジェクトへのコード修正パッチの提供、そして自身のトラブルシューティング経験をまとめた詳細な記事の公開などを行ってきました。 私にとって貢献とは、単にコードを書くことだけではありません。 それは、自分自身が初期段階で直面した困難を、他の人が乗り越える手助けをすることでもあります。 これからの未来について、私はDevOpsの実践とオープンソース文化が、より密接に結び付いた世界になると考えています。 今後の目標として、Kubernetes Certificationの取得、新たにLinuxを学び始める人々へのメンタリング、そしてコミュニティで自由に利用できるよう公開する自動化ツールの開発などがあります。 私の歩みは、オープンソースを受け入れることで、好奇心を専門的な能力へと変えることができることを示しています。 また、協力、学習、そしてテクノロジーへの情熱があれば、誰もがゼロから始めて、IT分野で充実したキャリアを築くことができるということを示しています。

MoodleMoot Philippines 2026：オープンソースが支えるデジタル教育の未来 教育分野は、コース開発向けのフリーかつオープンソースソフトウェアであるMoodleによって大きく発展しました。2002年にリリースされたMoodleは、教師やカリキュラム開発者が協力して教育コースを作成・共有するために利用されてきました。 フィリピンでは、Nephila Web Technology Inc.がデジタルラーニング分野の最前線で活動し、国内の学校や教育機関が拡張性と持続可能性を備えたオープンソースソリューションを導入できるよう支援しています。 そして、MoodleMoot Philippines 2026は、東南アジアのMoodleコミュニティにとって重要な節目となるイベントでした。このイベントは、フィリピン唯一のPremium Moodle Partner であり、同地域における先駆的な存在であるNephila Web Technology Inc.の創立15周年とも重なりました。 過去10年間にわたり、Nephila Webはデジタルラーニング分野の最前線で活動し、フィリピン各地の学校や教育機関が、拡張性と持続可能性を備えたオープンソースソリューションを導入できるよう支援してきました。 Linux Professional Institute（LPI）は今回のイベントに参加し、パネルディスカッションへの登壇とブース出展を行いました。LPIとNephila Webの関係は正式には2024年に始まりましたが、両組織の出会いは2023年にシンガポールで開催されたEduTech Asiaにまでさかのぼります。それ以来、オープンソースの普及、LPI認定資格の取得支援、教育分野におけるデジタルトランスフォーメーションの推進という共通の目標のもと、協力関係は着実に発展してきました。 パネルディスカッション：学習管理システムにおけるAI・セキュリティ・倫理 MoodleMootの中心的なセッションの一つとして、「学習管理システム（LMS）におけるAI、セキュリティ、倫理」をテーマにしたパネルディスカッションが開催されました。 この議論では、教育成果を高めながら、教育の信頼性を損なうことなくMoodle上でAIを活用した教育コンテンツを作成する方法について議論が行われました。 LPIのパートナー開発・成功支援マネージャー（APAC）として、私はこのパネルに参加し、必要なトレーニングや認定資格を測定可能な人材育成成果の一部として位置付ける、コンピテンシーベース（能力基準型）の職務定義の重要性について説明しました。 私が強調した主なポイントは、LPIのような認定資格は、単独で取得する資格として提示されるのではなく、具体的な雇用要件と結び付けられたときに、最も効果を発揮するということです。 Moodleを支えるオープンソース基盤 その他にも、注目すべき2つのパネルセッションがありました。 Nephila WebのCTOであるRoy Plomantes氏と、同社CEOであるSheryl Villaroman氏は、いずれも長年Linuxを支持してきた人物であり、Moodleの導入基盤としてUbuntuが非常に優れたプラットフォームの一つであることを紹介しました。 両氏の主張は実践的なものでした。Moodleの柔軟性とLinuxの信頼性は、非常に相性が良いという点です。 オープンソースは単にコスト効率が高いだけではありません。長期的なデジタル教育基盤を構築する教育機関にとって、戦略的な基盤を提供するものでもあります。 LPIブース：パートナーシップに関する交流 パネルセッション以外にも、LPIのブースには、技術チームや学生への認定資格提供を目的としてLPIとの連携に関心を持つ、国内外のさまざまな組織が訪れました。 これらの交流は、特にデジタル教育基盤が急速に拡大している地域において、世界的に認知されたオープンソース認定資格への需要が高まっていることを示しています。 来場者とは、LPIパートナープログラム、アカデミックパートナー制度、そしてLPI認定資格を既存の教育・トレーニングプログラムへどのように組み込むことができるかについて意見交換を行いました。 今後に向けて Nephila Webは今年、フィリピンのデジタル教育分野における15年間の貢献を祝いました。 MoodleMoot Philippinesは、オープンソースによる学習を推進する人々が集う、地域を代表するイベントとして成長を続けています。 Nephila WebとLPIのパートナーシップは、オープン性、協力、そして学習者や教育機関がオープンソース技術を導入できるよう継続的に支援するという、両組織に共通する価値観を反映しています。 今後もフィリピンおよび東南アジア全域におけるデジタル教育分野での共同活動を継続し、学習者、教育者、教育機関がオープンソースの未来で成長するために必要なツールと認定資格を提供していきます。

プログラミング言語の盛衰（前編） プログラマーには、それぞれお気に入りのプログラミング言語があります。それは、スポーツファンが地元や母国のチームを応援するのとよく似ています。 Luaのように非常に限定的な分野で使われ、その熱心な利用者から高く評価されている言語もあります。一方で、CやC++のように、まるで不滅であるかのように使い続けられている言語もあります。しかし、多くの言語は、登場当初には将来を期待されながらも、やがて静かに姿を消していきました。 本シリーズでは、そうした重要なプログラミング言語の栄枯盛衰を2回に分けて紹介します。 不滅の言語 C言語は、1970年代初頭にUnixオペレーティングシステムとともに誕生しました。 CとUnix（現在ではLinuxやBSD）は切っても切れない関係にあり、この強い結び付きが現在でもC言語が使われ続ける大きな理由となっています。しかし、Cにはそれとは別に、言語そのものとしての魅力もあります。 Cは習得しやすく、扱いやすい一方で、誤った使い方もしやすい言語です。しかし、高水準言語では実現が難しいほど高速に実行できるという大きな利点があります。（一方、C++は正しく扱うための難易度がさらに高くなります。） そのため、多くの新しいプログラミング言語では、C/C++で作成されたライブラリを利用できる仕組みが用意されています。実際に、PythonのNumPy、SciPy、TensorFlowといった重要なライブラリでは、この仕組みが積極的に活用されています。 もっとも、CやC++はすべての用途に適しているわけではありません。バッファオーバーフローのような古くから知られるプログラミングミスやセキュリティ上の欠陥を防ぐ仕組みが十分ではありません。現在ではAIやファジング、各種コード解析ツールによって、こうした問題が頻繁に発見されるほどであり、もはや言語の特性の一部とも言えるほどです。 そのため、CやC++は、長期間にわたって大きな変更が行われず、最高レベルの実行性能が保守性よりも重視されるようなソフトウェアに適しています。 JavaScriptも、不滅の言語に分類できる唯一の存在です。 JavaScriptには批判的な意見も少なくありませんが、ブラウザがネイティブでサポートしている高水準言語はJavaScriptだけです（低レベル言語であるWebAssemblyを除く）。そのため、動的なWebページを実現するためには、依然として欠かせない存在となっています。 その結果、CoffeeScriptやElmのような拡張言語や、多数の強力なライブラリによってJavaScriptを補完しながら利用するという文化が発展しました。こうした豊富なライブラリ群は、あらゆるプログラミング言語の生命線とも言えます。 Javaもまた、CやC++と同じような長寿言語になる可能性があります。 Javaは1995年に「より優れたC++」として、さらにWebブラウザ上でも動作する移植性の高い言語として登場しました。当時のコンピューター業界では、オブジェクト指向プログラミングが大きな注目を集めていました。 現在主流となっているJava、Python、JavaScriptなどを見ても分かるように、オブジェクトは現代プログラミングの基本的な構成要素となっています。 Sun Microsystemsが開発したJavaは、大規模な企業システムにおける標準的なプログラミング言語となり、現在でもコンピューターサイエンス系の大学教育で最も広く教えられている言語の一つです。また、より新しい言語から生まれた優れた機能を積極的に取り入れながら進化を続けています。 一方、Sun Microsystemsと激しく競争していたMicrosoftはJavaをそのまま採用することを避け、2000年に対抗するオブジェクト指向言語としてC#を発表しました。 C#の支持者の中には、Javaよりも優れていると主張する人もいます（Java初期の設計上の問題を改善したとも言われます）。しかし、オープンソースのMono Projectによるサポートがあったにもかかわらず、C#がJavaを追い抜くことはありませんでした。 現在のC#の主な役割は、Microsoftの包括的な.NETフレームワークを支えることです。 PHPは、動的Webページのサーバーサイド処理を目的として開発されましたが、多くの人の予想以上に長く生き残っています。 現在でも非常に多くのWebサイトで利用されており、ある調査では全Webサイトの71％がPHPを利用しているとされています。 PHPも他の成功した言語と同様に、初期の欠点を改善しながら進化を続けてきました。 プログラミング言語も企業と同じで、まずは「必要最低限の実用製品（MVP）」を提供し、その後に改良を重ねていくという考え方は理にかなっていると言えるでしょう。 不滅の言語という観点では、多くの開発者がRustにもその仲間入りを期待しています。特に、新しいシステムではCやC++の代わりとして利用されることが期待されています。 しかし、Rustがその期待に応えられるかどうかを判断するには、まだ時期尚早です。私自身は、その可能性はあまり高くないと考えています。 理由は、Rustが多くのプログラマーにとって複雑すぎ、抽象度も高すぎるからです。そして、複雑さは設計上の問題を生みやすくなります。本番環境で広く利用されることを目指すプログラミング言語にとって、それは大きな弱点となり得ます。 一時代を築いた言語たち 一方で、特定の時代に重要な役割を果たし、その後は徐々に姿を消していった言語もあります。 代表的なのがCOBOLとFORTRANです。 COBOLはビジネス分野で、FORTRANは科学技術計算の分野で圧倒的な存在感を誇りました。FORTRANのベテラン開発者は、「人類を月へ送り届けたのはFORTRANだった」と誇らしげに語ることがあります。 企業や研究者がこれらの言語を積極的に採用したのは、その時代の要求に非常によく合っていたからです。 これらの言語は数世代にわたって経済発展や科学技術の進歩を支えました。しかし、ソフトウェア開発がより専門的になるにつれて、保守性やセキュリティが重視されるようになり、やがてCOBOLやFORTRANの役目は終わりを迎えました。 もっとも、プログラムは言語よりも長生きすることがあります。 COBOLの重要性は1990年代後半の2000年問題（Y2K問題）によって改めて注目されました。そして現在でも、COBOLプログラマーは必要とされています。 私自身、ずいぶん昔にテクニカルライターの仕事のためにCOBOLを学びましたが、それほど難しい言語ではありませんでした。そのため、意欲のある若いプログラマーであれば比較的短期間で習得し、高齢化したベテラン技術者に代わって活躍できるでしょう。 ところで、「まだ○○ではこの言語が使われています」と教えてくださる必要はありません。 自然言語を例に考えてみてください。 ラテン語は紛れもなく「死語」ですが、現在でも参加者全員がラテン語だけで会話する国際会議が開かれていますし、バチカンでは公式文書のためにラテン語辞典が更新され続けています。 また、ヘブライ語は紀元前500年頃には日常会話としては使われなくなりましたが、その後も詩人たちは書き言葉として使い続け、20世紀には再び日常語として復活しました。 サンスクリット語も、現在では話者は少ないものの、宗教儀式では今なお重要な役割を果たしています。 FORTRANプログラマーたちは、パンチカード時代の制約を色濃く残した記法で、IやJといった単純な変数名を使い、ほとんどコメントも付けず、大量の保守しにくい関数を書き続けました。こうしたコードは「スパゲッティコード」と呼ばれています。 次回の記事では、この問題を解決しようとしたコンピューターサイエンス研究者たちの取り組みを紹介します。 FORTRANは科学技術計算の世界にあまりにも深く浸透していたため、その開発者の一人は「2000年のプログラミング言語がどのようなものかは分からない。しかし、その名前はFortranだろう」と語ったことで有名です。 しかし、コンピューターサイエンスそのものが進歩し、FORTRANでは対応できない要求が増えていきました。 開発者たちは「Fortran 8X」というコードネームで新バージョンの開発を長年続けましたが、あまりにも完成が遅れたため、「Xが16進数になってしまった」と冗談を言われるほどでした。そして最終的に、その言語はFortran 90としてリリースされました。 ちなみに、私がフリーランスとしてO'Reillyで最初に編集を担当した書籍はFortran 90に関するものでした。この本は高い評価を受けたものの、商業的には成功しませんでした。 BASICも忘れてはならない言語です。 1963年に、プログラマーではない人でも簡単にプログラミングできることを目的として開発され、オフィスワーカーやアマチュアプログラマーの間で爆発的に普及しました。 その後、MicrosoftはVisual Basicを発表し、IDEも備えたWindows向けのグラフィカルアプリケーション開発言語へと発展させました。 さらに、UnixからPerlなどのスクリプト言語が登場した後も、BASICはしばらく日常的に利用され続けました。 そのため、COBOLやFORTRANほど中心的な存在ではなかったものの、アマチュアプログラマーという重要な層を支え、長期間利用された言語として、この分類に含めています。 Perlもまた、「一時代を築いた言語」の代表格です。 Perlは、システム管理者が日々の作業を自動化したいという要求に真正面から応えた最初のスクリプト言語でした。これはDevOpsという概念が生まれる20年以上も前のことです。 Perlはシステム管理者にとって欠かせない存在となり、さらにWorld Wide Webサーバー上で動的Webページを実現する最初の実用的なプログラムを支えるという栄誉も手にしました。 Perlは非常に自由度が高く、プログラマーの創意工夫をさまざまな方法で表現できる言語でした。しかし、その自由度は長い目で見ると、あまりにも大きすぎました。 Perlプログラマーの間では、「1行でどれだけ多くの処理を書けるか」を競う文化さえありました。 私自身、以前保守を担当することになったPerl 4のプログラムは、 $firstline or print ... のような記述ばかりで構成されていました。 Perlでは「or」は演算子ですが、そのプログラムを書いた開発者は制御構文のように使っていました。 この1行は、「変数$firstlineが設定されていなければ、後続の内容を表示する」という意味です。（LISPの「遅延評価」にも似ています。） 最終的に私は、そのプログラム全体が、$firstlineのような大量のグローバル変数によって状態を管理する、非常に複雑な状態遷移システム（ステートマシン）であることに気付きました。 こうしてPerlは、現在でも一部のレガシーシステムでは使われているものの、多くの競合言語にその座を譲ることになりました。 その代表が、現在主流となっているPythonです。 そのほかの競合言語については、本シリーズの後編で紹介します。