Aikの技術日記

技術的な進捗とか成果とかを細々と投稿するブログです。時々雑記も。

Theiaで自作IDE構築をしよう その1(余談-前編)

はじめに

先日書いた記事Theiaで自作IDE構築をしよう その1にて出てきた、聞きなれない事柄や単語をまとめていきたいと思います。

では、早速行きましょう。

TypeScriptとは

www.typescriptlang.org

TypeScriptは、Microsoftによって開発されたオープンソースプログラミング言語です。
JavaScriptの拡張言語となっており、JavaScriptのプログラムはTypeScriptとしても見做すことができます。

拡張された機能として主たるものは「静的型付け」と「クラス構造」です。
C#設計に関わったアンダース・ヘルスバーグという方も開発に携わっているだけあって、C#Javaの様な言語を触ったことがある方にとっては、JavaScriptよりもTypeScriptの方が学習しやすい…とのことです。

なお、このTypeScriptは大規模なプロジェクト向けに設計されているみたいです。
まぁクラス構造とかは大規模開発に向いてますからね…。

そのため、簡単なコードを書くならJavaScriptや、CoffeeScript(これもまたJavaScriptの拡張言語です)の方がいい場合もあるとのこと。

こちらの記事にとても分かりやすく書かれていたので、下記に引用させていただきました。
長いので折り畳んでます。

展開する

迅速性: 何かを設定する時はJavaScriptを使った方が早くできます。
型システムでないことで、非常に軽く、内容を簡単に変更することも可能です。
もちろんコードは簡単に壊れてしまうものでもありますが、自分が何をしているのかが分かっていれば、JavaScriptの方が柔軟性を備えていると言えます。
型システムのユースケースの中には、コードを壊れにくくするということがあるのを思い出してください。

例えるならTypeScriptはWindowsで、JavaScriptLinuxのようなものです。
JSの世界には、型システムの”補助輪”はありませんし、自分が何をしているか分かっているのが当然とされます。
しかし、より速く、より簡単に操作できます。
特にプロトタイプ制作の段階にいるのなら、TypeScriptで時間を無駄にしないでください。
JSはより機敏で融通がきくからです。
TSはJSのスーパーセットです。つまり、後から簡単にJSをTSに変換できるのです。
もしも型付き言語を使っているのなら、IDEでコードを書く/最適化するのも速くなるかもしれません。
型システムは機械が構文を理解するのを手助けするからです。

※参考記事: TypeScriptを使った方がいいケースとは? | POSTD

参考に、TypeScriptで追加された具体的な機能を載せておきます。
※こちらも長いので折り畳んでます、あとソースはWikipediaさんです

展開する TypeScriptはJavaScript(ECMAScript 5)に次のような言語機能の拡張を加えたものである。

  • ECMAScript6由来
    • クラス
    • アロー関数式(ラムダ式)
    • オプション引数、デフォルト引数
    • let, const
    • テンプレート文字列: 文字列内への変数埋め込み
    • モジュール
    • for/of
    • 分割代入
    • Symbol
  • ECMAScript7由来
    • デコレーター
    • Async/Await
  • TypeScript独自

構文的には、静的型付けやクラス、継承、インタフェースのようなオブジェクト指向名前空間などの機能を追加する、ECMA-262言語標準のマイクロソフトによる実装である JScript.NETとTypeScriptはよく似ている。

そして、TypeScriptについてよく言われるのが「なんでJavaScriptじゃなくてTypeScriptの方がいいの?」という疑問。
コンパイルしたらJavaScriptになるんだから、別に使わなくてもという意見が多いみたいです。
ならどうして使うかというと…下記のようなメリットがあるかららしいです。

  • C#Javaのような強い性的型付け言語を学んでる人にとって学びやすい
    • TypeScriptの開発者はCの作者と同じ
  • ES6,ES7で導入された機能(Classとか)やその他独自機能(Interfaceとか)が備わっている
    • 実質TypeScirptをBabelのように扱うことも可能
    • ※ESに関しては筆者の書いたこちらの過去記事を参照に

また、TypeScriptでは導入されているクラス構造…JavaScriptでも書けるのですが、書くコストがかなり膨大みたいで…。
この辺りについては下記の記事に、コード付きで詳しくまとめられておりました。参考に…。
TypeScriptを使う理由 - Qiita

最後に…。
TypeScriptを少し試してみたいという場合、TypeScript公式サイトのPlaygroundタブよりそのお試しが出来る様です。
デフォルトで"Hello, World"プログラムが記載されているので、よければ|д゚)
TypeScript: TS Playground - An online editor for exploring TypeScript and JavaScript

※この章の参考記事はこちら↓
TypeScript - Wikipedia
CoffeeScript と TypeScript をそれぞれ実務案件で使ってみた感想 | DevelopersIO
TypeScriptを使った方がいいケースとは? | POSTD
第1回 TypeScriptの概要 (1/4):TypeScriptで学ぶJavaScript入門 - @IT

LSP(Language Server Protocol)とは

microsoft.github.io

Language Server ProtocolはMicrosoftが公開した定義で…うん、詳しくは下記の引用文をご覧ください。

language serverとは、IDEが必要とするプログラムのプロジェクトソースを解析して情報を提供する機能を、サービスとして実現するものです。
language serverがサポートされたIDEでは、型やメンバーの自動補完、変数やメンバーの定義参照、変数やメンバーの利用箇所の検索、コードの自動フォーマット、コードのエラー分析や修正案の提示といった、さまざまな機能を実現できます。

Microsoftの技術で言えば、Roslynが最も近い存在であると言えます。
あるいは、TypeScriptは、最初からlanguage serverの実現を意図しながら開発された言語でした。

language server protocolとは、このlanguage serverとそのクライアントを接続する仕組みを、プロトコルとして規定したものです。
サーバーの実体は主にプログラミング言語環境、クライアントの実体は主にテキストエディタIDEということになります。
プロトコルJSON-RPCで規定されています。(これが2000年代だったらSOAPで規定されていたかもしれませんね…!)

今回Microsoftがこのlanguage server protocolで提案したのは、language serverの機能というものは、プログラミング言語のいずれかを問わず、コンパイラインフラストラクチャーの類にある程度は共通しているので、それを取り決めてしまおう、というものです。
これが実現すれば、どのIDEテキストエディタでも、この仕様で定めるプロトコルのクライアントを実装すれば、その接続先にあるサーバーがいかなる言語を取り扱っていても処理できるようになります。
逆に、どのプログラミング言語でも、この仕様が定めるプロトコルのサーバーを実装すれば、どんなクライアントが接続してきても、画一的に対応できるようになります。

※参考記事: language server protocolについて (前編) - Qiita

概要は上記の様な感じだそうです。
正直、引用元の記事が本当に素晴らしくて…Language Server Protocolに関する様々なことがこの1記事にたくさん書かれてありました。
Language Server Protocolに関しては、上記記事を見てもらえばかなり理解出来ると思います。

また、公式サイトが本当にしっかりしているので…。
英語が得意な場合はそちらを見た方が理解が深まるかと。
(自分は英訳する気になれませんでした…許して)

なお、公式ページのOverviewを見てみると、いくつかの言語でこの実装を簡単にするべくライブラリがあるみたいです。
※例えばJavaScript/TypeScript用のlanguage client npm modulelanguage server npm moduleとか

JSON-RPCとは

www.jsonrpc.org

先の項目(Language Server Protocol)にも出てきた「JSON-RPC」。
こちらはRPC(Remote Procedure Call)というものを実現するプロトコルの1つらしいです。

…うん、RPCってなんじゃ。というわけでちょっと調べてみました。

遠隔手続き呼出し(英: remote procedure call、リモートプロシージャコール、略してRPC)とは、プログラムから別のアドレス空間(通常、共有ネットワーク上の別のコンピュータ上)にあるサブルーチンや手続きを実行することを可能にする技術。
その際に遠隔相互作用の詳細を明示的にコーディングする必要がない。
つまり、プログラマはローカルなサブルーチン呼び出しと基本的に同じコードをリモート呼び出しについても行う。

※参考(Wikipedia): 遠隔手続き呼出し - Wikipedia

なるほど…分散システムの分野と非常に深い関わりがありそうなものですな。
なお、カテゴリとしてはプロセス通信に属する項目みたいです。

話をJSON-RPCに戻すと…、このJSON-RPCとは、このRPCプロトコルJSON形式で行う(エンコードJSONを採用した)プロトコルみたいです。
RPCからより具体的になった感じですね。

また、非常にシンプルなプロトコルとのこと。
RPCのプロトコルの有名どころとしては、RESTというものがあるそうですが…そちらは結構複雑なプロトコルらしく、RESTに疲れた戦士たちがJSON-RPCを使ってみるという記事も散見されました。
※例: JSON-RPCというWebAPI設計に役立ち、、そうなそうでもないかもな規格 - Qiita
REST APIに消耗したらJSON RPCを試そう - タオルケット体操

なお、RESTに関してはこちらを…すごく分かりやすかったです。
「Webを支える技術」を読みました とRESTのまとめ - 大学生からの Web 開発

JSON-RPCについて詳しくは、こちらも非常に分かりやすい参考記事があったので…その一部を引用させていただくという形にします。
なお、引用した文は一部分ですので、より理解を深めたい場合は参考記事を直接見てみることを勧めます。

例えば、次のようなリクエストをJSONで送ると、別のマシンで subtract(42, 23) が実行され、結果の 19 がレスポンスとして返ってきます。
request:

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

response:

{"jsonrpc": "2.0", "result": 19, "id": 1}

プロトコルの仕様でしかないため、どう実現されるかは個別の実装に委ねられる点に注意してください。
JSONを使ったシンプルなやりとりになるため、Webブラウザやモバイルアプリなどのクライアントからサーバーへ通信するときだけでなく、マイクロサービスにおけるサーバー間の通信にも利用できます。

※参考記事: JSON-RPCって何? - Qiita

そう言えば、Theia記事その1でこんな風な文章を書いていました…。

そして、フロントエンド部分とバックエンド部分同士の通信は下記の様に行われているそうです。
- ブラウザアプリケーションとして実行: JSON-RPCメッセージを通じたHTTPのWebSocketまたはREST API通信

今となってはなんとなく理解できる様な…。
また、Language Server ProtocolはJSON-RPCで規定されているとのことでしたので…。
Theiaでこれが使われているのも、そういうことなのでしょうかね…?純粋にJSON-RPCを選んだだけかもしれませんが…。

WebSocketとは

WebSocketとは、Webアプリケーションにおける双方向通信を実現するための規格です。
似た様な技術としてAjaxがあげられるそうですが…WebSocketは、このAjaxの根幹技術「XMLHttpRequest」の欠点を補う技術として開発されているそうです。

詳しくは下記を…。

WebSocketとは(Wikipedia):
XMLHttpRequestの欠点を解決する技術として開発されており、現在のComet等に取って代わることを目標としている。

いわゆるAjaxアプリケーションではサーバとクライアント間のデータのやり取りが頻繁に発生するが、従来のXMLHttpRequestはあくまでブラウザ側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。
一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとにTCPのハンドシェイク手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる(XMLHttpRequest#ロングポーリングも参照)。

これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。
従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。

なかなかいい感じの技術っぽいですね。
また、非常に参考になる記事やSlideShareのスライドを下記に載せておくので、参考に。

こちらはSlideShareより。
WebSocketに関する概要を図示されながら非常に丁寧に書かれてあります。
とっても分かりやすかったので、まずはここを見てみるといいかも。

WebSocketについて調べてみた。 - Qiita
こちらはWebSocketについてかなり詳しくまとめられています。
実際に使われるリクエスト文とともに解説がある…めちゃすごいぞ…。
先のスライドとこの記事を読めば、だいたい概要は理解できると思います。

RFC 6455 - The WebSocket Protocol (日本語訳)
こちらはWebSocketの仕様書の日本語訳です。
モノホンの仕様書の訳なので、WebSocketの全てがここに記載されています。
上記の参考記事を見た後なら多少は読める様になると思いますが…。

WebSocketでチャットアプリを作ろう① ~WebSocketサーバの立て方~ | モナカプレス
こちらではWebSocketを使って、JavaScriptでデモアプリを作られております。
実際のソースコードも見れるため…WebSocketをどの様に実装するのか見てみたいって場合に非常に参考になるかと。

まさかの後編へ

さて、まだまだ調べたい単語や項目はあるのですが…。
長くなりそうなので、この余談も前編と後編に分けようと思います…。

正直ここまで長くなるとは…。
自分が如何に技術的な知識のBackground的…もしくは基礎的なものを理解してなかったのかが良く分かりました。
ひとまずは後編で…。