Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/04/01)へのリンクMozillaは先頃、あらゆるデバイス、マシン、オペレーティングシステムで同じWebAssemblyコードを実行することを目的とした、新たな標準化の取り組みを発表した。Interface(WASI)では、複数の実際のオペレーティングシステムで実装可能な、概念的な単一のオペレーティングシステムインターフェイスを定義する。Anywhere"の取り組みとは異なり、WASIは、ブラウザベンダとチップやデバイス、コンピュータ、オペレーティングシステムの製造業者という、これまでにないコラボレーションによって生み出された、特許フリーのオープンスタンダードであるWebAsemblyの上に構築されている。WASI標準は、標準インタフェースのモジュールセットを通じたWebAssemblyの移植性とセキュリティの提供と、エコシステムのための堅牢な基盤の提供を目標とする。MozillaとFastlyがすでに、WASI実装のプロトタイプを提供している。WASIが目指すのは、WebAssemblyプラットフォーム(現在主要な4ブラウザエンジンによって実装されている)のシステムインタフェースになることだ。WebAssembly(Wasm)は、それ自体を"スタックベースの仮想マシン用のバイナリ命令フォーマット"であると定義して、"広範なプラットフォームで利用可能な共通ハードウェア機能を利用することによる、ネイティブスピードの実行"を目標に設計されている。WasmはC、C++、Rustといった高級言語のコンパイルターゲットとして使用される。Web上での動作を中心に設計されていたが、Mozillaは現在、その範囲をWeb埋め込み以外の、"テスト用の最小限のシェルから、データセンラのサーバ上やIoTデバイス上、あるいはモバイル/デスクトップアプリといった本格的なアプリケーション環境まで"拡張しようとしている。Clark氏の見解によれば、ブラウザ外のコードには、システムと対話する手段、すなわちシステムインターフェースが必要です。WebAssemblyプラットフォームには、まだそれがありません。Anywhere"に通じるものがある。Machine(JVM)は確かにこれと同じような目的を持っており、WebAssemblyプラットフォームが提供するものと同じような言語の柔軟性が、GraalVMを通じてJavaで実現されている。Javaはデファクト標準に留まっている上に、所有者であるOracleは、GoogleがJavaのAPIを違法に使用しているとして訴訟を起こしており、現在も係争中である。対照的にWebAssemblyは、Microsoft、Google、Apple、Mozilla、Intel、Samsungなどのブラウザベンダや主要企業による前例のないコラボレーションなのだ。Franciscoで、次の点を強調している。(...)このような企業が集結しました。最初の標準化バイトコードは、これら業界の主要企業がすべて参加して開発されたのです。プロプライエタリなプログラムではありません。疑問の余地なく、完全にオープンです。特許法や、それに類するものに妨げられることはまったくないのです。Wasmはメモリセーフであり、バリデーションを備えているため、Javaに対してセキュリティ上のメリットがあると考えられる。Schneidereit氏はさらなる意見で、Wasmを支持している。WebAssemblyは、小規模デバイスから大規模なサーバーファームやCDNにまで拡張できるように設計されています。Javaよりも言語非依存であり、実装上のフットプリントもはるかに小さいのです。WASIは、システム機能の抽象化を基盤として、複数のシステムに対する共通インタフェースを規定することによって、移植性のあるバイナリを実現しようとしている。このような抽象化はモジュールにまとめられており、wasi-coreが中核的な役目を担っている。Clark氏が詳しく説明する。wasi-coreには、すべてのプログラムに必要な基本部分が含まれていて、ファイルやネットワーク接続、クロック、乱数など、POSIXと同じ分野の大半をカバーしています。その他の3Dグラフィックスやスマートコントラクトといった機能は、専用のモジュールを用意して対処することになる。標準化の活動は、WebAssemblyのパフォーマンス上の目標を維持しつつ、数多くのオペレーティングシステムとアーキテクチャに対応するために、システム機能の抽象化を慎重に規定することを目標としている。WASIは、機能ベースのセキュリティモデルを採用することによって、Wasmのセキュリティ面に目を向けている。WASIアプリケーションには、リソースに対する適切なアクセス権を指定しない、(ファイルパスのような)偽造可能なリファレンスに代えて、ケーパビリティによるリソース識別機能が提供される。authority)に基づく検証の実施が必須となる。Clark氏は、WASIアプリケーションがファイルをオープンする権限を事前に付与されている場合にのみ、そのファイルをオープンできる方法について説明する。/etc/passwdを適当に開くことはできません。プログラムが操作できるのは、それに渡されたディレクトリに限定されます。そのためにランタイムは、アプリが操作可能なファイルディスクリプタをトップレベルのコードに渡します。そのファイルディスクリプタが、必要に応じてシステムの他の部分に伝搬されるのです。WASI対応アプリケーションは、現時点ではpolyfillを備えたブラウザ内か、あるいはMozillaのWasmtimeまたはFastlyのLucetを使ってブラウザ外で動作可能である。WASIは現在開発中である。Clark氏は次のように振り返る。wasi-codeが完全に標準化された後に対処しなければならない、次のような問題が残っています。非同期I/Oファイル監視ファイルロックリスクは高い。WASM+WASIが2008年に存在していれば、Dockerを開発する必要はありませんでした。それほど重要なものなのです。サーバにおけるWebassemblyは、コンピューティングの未来です。