コロナ禍におけるエンジニアのためのCloud IDE
2020年3月頃からコロナが流行りだし、もう12月になります。働き方が大きく変わり、リモートワークが当たり前の時代となりました。 エンジニアの働き方も同様に変わりました。そこで、今回はCloud IDEというものを紹介しようと思います。
リモートワークとDaaS
リモートワークが増えると、DaaSのようなサービスを利用する企業が増えたのではないでしょうか。 DaaSの簡単な説明を引用しますと、次のとおりです。
DaaSとは、“Desktop as a Service”の頭文字を取った略語で「ダース」と読みます。 普通ならば個人のPCにデスクトップは存在し、データは個人のPC内に保存されていますが、DaaSにおいては個人のデスクトップがクラウド上に構築され、ネットワークを通じてそのデスクトップを呼び出して利用することになります。 ここでは、DaaSとはどういう仕組みなのかを説明し、その必要性、メリットについて詳しく述べていきます。
DaaSはクラウドサービスの一種で、特定のソフトウェアを端末にインストールすることなく、ネットワークを通じて利用できるという特徴があります。 クラウド上にあるデスクトップ環境を呼び出して利用できるため、個人のPCはディスプレイとキーボードなど必要最低限の機能があれば良いので、テレワークをするために高いスペックのPCを用意する必要はありません。
※ https://www.ascentech.co.jp/solution/column/daas.html
例えば、クラウド上で開発環境(お気に入りのエディタ, プログラミング言語, 使い慣れたツール, etc)を構築して、そこにアクセスして仕事をするようになります。アクセス元は、私物のPCや会社から支給されているPCなどが多いと思います。
Cloud IDE
Cloud IDEは、クラウドにある統合開発環境(IDE)のことで、主にブラウザから操作できるようなものが多いです。 ざっと有名なものをリストアップしてみました。
提供元 | IDE名 |
---|---|
Microsoft Azure | Visual Studio Codespaces |
Github | Codespaces |
Amazon Web Services | Cloud9 |
Google Cloud Platform | Cloud Shell Editor |
Coder | Coder |
OSS | Gitpod |
ブラウザで見ると、どんなUIでしょうか。いくつか例を載せておきます。
Cloud Shell EditorやGitpodは、OSSの Theia というものを使っています。 また、全体的にUIがとても似ていますよね。これは、次の記事でわかりやすく説明されていますので、ご興味があればお読みください。
これらのCloud IDEは、ここ最近Publickeyでよく目にします。記事と投稿日時をまとめてみました。
- Visual Studio Codeの代替を狙う統合開発環境「Eclipse Theia 1.0」リリース。VS Codeの拡張機能を利用可能、デスクトップ版とWebブラウザ版に両対応 - Publickey
- 2020年4月3日 投稿
- GitHub、WebIDEの「Codespaces」を発表。GitHubからワンクリックで開発環境へ。GitHub Satellite 2020 - Publickey
- 2020年5月7日 投稿
- マイクロソフト、WebIDEの「Visual Studio Codespaecs」を「GitHub Codespaces」に統合へ - Publickey
- 2020年9月7日 投稿
- GitHub/GitLabとの統合用WebIDE「Gitpod」がオープンソースで公開。GitHub Codespacesを先取りする開発環境 - Publickey
- 2020年9月11日 投稿
- Google、VSCodeの代替を狙う「Eclipse Theia」コードエディタをクラウド統合開発環境として採用。Google Cloud Shellに統合を発表 - Publickey
- 2020年11月10日 投稿
稚拙な推測ですが、リモートワークが普及し、働く環境も変化したためかなと思っています。 物理的なPCで開発するのではなく、クラウド上にあるPCで開発する、それが当たり前になるのかなと。
Theia
Theiaとは何か、Githubのaboutより引用します。
Eclipse Theia is a cloud & desktop IDE framework implemented in TypeScript
※ https://github.com/eclipse-theia/theia
このOSSの興味深いところの1つに、設計書が公開されているところです。
Theiaは、ローカルで動かすことができます。Webアプリだけじゃなく、ネイティブアプリ(Electron)もあります。
また、Dockerコンテナも公開されています。
ベンダーニュートラルなので、VMインスタンスにTheiaを入れて独自に運用するなど、ベンダーに依存しません。
個人的な話
個人的に、Gitpodを使いたいのですが無料だと月50時間までしか使えません。
"Professional Open Source" というものを応募したところ、Gitpodの組織 へ招待頂き、公開リポジトリの無制限利用ができるようになりました。
Gitpodを使い続けて思うこと
Gitpodは、.gitpod.ymlというファイルで環境構築されます。
ベースとなるDockerイメージを指定して、必要なライブラリを事前にインストールできたりします。 公式ブログに、Gitpodの完全ガイドがあります。
また、様々なOSSをGitpodで簡単に動作確認できます。
実際にGitpodを使ってみると、確かに便利です。 アクセス元のPCは、非力なノートPCでも良く、GithubのRepository毎にGitpodのコンテナがあるため、相互に影響しません。 ただ、ネットワーク遅延でちょっと待ったり、Gitpodのショートカットキーより、ブラウザのショートカットキーが上書きされて困ることが多少あります。
終わりに
ブラウザ上で開発するのって、昔からあったように思いますが、あんまり注目されていなかったのでしょうか(私が無知なだけかもしれません)。 AWSやGCP、Githubなど各社が積極的に手を出しているところを見ると、これからますます期待できる分野なのだと思います。
TypescriptでArchUnitしてみた
ArchUnitをというものを最近知りました。依存関係のテストができるそうです。さっそく試してみたいと思いますので、その備忘録として残しておきます。
ArchUnit
ArchUnit is a free, simple and extensible library for checking the architecture of your Java code using any plain Java unit test framework. That is, ArchUnit can check dependencies between packages and classes, layers and slices, check for cyclic dependencies and more. It does so by analyzing given Java bytecode, importing all classes into a Java code structure.
Javaのアーキテクチャをテストできるライブラリで、パッケージやクラス、レイヤー、スライス(?)の依存関係をテストできるそうです。 そこで、親の顔よりも見たこの図をテストしたいと思います。
※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
TypescriptでもArchUnitしたい
ArchUnitはJava製です。私はTypescriptのArchUnitがしたいです。 そこで、良さげなライブラリを発見しました。
特に拘りなく、アーキテクチャのテストができれば何でも良いかなと思います。 極端な話、ソースコードをASTパースし、依存関係を抽出できれば自作できるんじゃないかと思います。
試してみた
試したソースコードは、下記に置いています。ご参考下さい。
全体のソースコードツリーは次の構成です。
src └ 1_enterprise_business_rules └ entities └ Entity.ts └ 2_application_business_rules └ use_cases └ UseCase.ts └ 3_interface_adapters └ controllers └ Controller.ts └ gateways └ Gateway.ts └ presenters └ Presenter.ts └ 4_frameworks_and_drivers └ web └ Web.ts └ clean_architecture.puml └ clean_architecture.test.ts
各プロダクトコードは、下の階層のファイルをimportしているだけとします。
// src/4_frameworks_and_drivers/web/Web.ts import "../../3_interface_adapters/gateways/Gateway" import "../../3_interface_adapters/controllers/Controller" import "../../3_interface_adapters/presenters/Presenter"
// src/3_interface_adapters/controllers/Controller.ts import "../../2_application_business_rules/use_cases/UseCase"
// src/2_application_business_rules/use_cases/UseCase.ts import "../../1_enterprise_business_rules/entities/Entity"
// src/1_enterprise_business_rules/entities/Entity.ts
下記ファイルにあるUMLのコンポーネント図で依存関係を表します。
# clean_architecture.puml @startuml component [4_frameworks_and_drivers] #Blue component [3_interface_adapters] #Green component [2_application_business_rules] #Red component [1_enterprise_business_rules] #Yellow 4_frameworks_and_drivers --> 3_interface_adapters 3_interface_adapters --> 2_application_business_rules 2_application_business_rules --> 1_enterprise_business_rules @enduml
UMLを可視化すると、下記の図のとおりです。
テストコードは、下記のとおりです。
// clean_architecture.test.ts describe("architecture", () => { it("Check dependency", async () => { const architectureUml = path.resolve(__dirname, "clean_architecture.puml"); const violations = await slicesOfProject() .definedBy("src/(**)/") .should() .adhereToDiagramInFile(architectureUml) .check(); await expect(violations).toEqual([]) }); });
このテストケースはPASSします。
では、違反コードを書いてみます。
// src/3_interface_adapters/controllers/Controller.ts import "../../2_application_business_rules/use_cases/UseCase" import "../../4_frameworks_and_drivers/web/Web"
3レイヤーが上位の4レイヤーを使用しています。この状態でテストを実行すると、
見事Failedとなりました。つまり、依存関係の誤りを自動的に検出することができます。
最後に
規模が大きなプロジェクトほど、依存関係が複雑になりがちです。(Javaでいう) パッケージやクラスの依存関係を適切に設計できていたとしても、誰かが壊しかねません。せっかく設計したのに壊されるのは、とても残念なので、テストコードで守ってあげましょう!
Cloudflare Workers (Edge Workers) で Micro Frontends
今回、またMicro Frontendsの構築を試みようと思います。構築パターンの内、サーバーサイド統合パターン、特にエッジサイド統合を試しました。 その内容を紹介します。サンプルコードは、下記に残しています。
Edge Side Include (ESI)って?
ESIは、SSIと似たようなもので、サーバーサイド側でコンテンツを挿入する仕組みの1つです。ESIの場合、挿入するコンテンツ(ページフラグメント)がEdge側にあると理解しています。 そのため、Edgeキャッシュをコンテンツ毎に効かせれるメリットがあります。 現状、ESI言語仕様はW3Cへ提出していますが、承認が降りていない状況です。AkamaiなどのCDN企業や、Varnishなどのキャッシュプロキシサーバは、ESIを一部実装しています。
個人で試すのに、Akamaiは金銭的に厳しいですし、varnishのVCLを記述したくない(好き嫌い)です。 そこで、Edge Workerと呼ばれる仕組みを試そうと思います。
次の引用はAkamaiブログからです。
EdgeWorkersは、世界中に分散配置されたAkamaiのEdgeサーバー上で、カスタムしたプログラムコードを実行できるようになる新しいサービスです
※ https://blogs.akamai.com/jp/2019/10/edgeworker.html
要は、Edge WorkersとはCDNが提供するプラットフォーム上で、プログラムコード、例えばJavascriptなどが実行できるサービスです。
Edge Workers
個人で使えるEdge Workersだと、fly.ioやCloudflare Workers があります。後者のCloudflare Workersには、HTMLRewriter というHTMLを書き換える機能があり、Micro Frontendsに使えそうだったため、今回はCloudflare Workersを使用します。
構成
次のような構成を考えてみました。
※ PodiumとAra-Framework に影響されています。
※ draw.ioのsketch styleで書きました。
それぞれのブロックがCloud Workersとなります。
簡単に、図の左から右の順に説明していきます。 Routerで、Webアプリケーションのルーティングを管理します。 ルーティングでは、HTTPリクエストの内容に基づいて、どのページか振り分けます。 振り分けられたページでは、後述するフラグメントを含めてHTMLを構築します。 そのHTMLをHTMLRewiterで処理し、Proxyに存在するフラグメントがあれば、フラグメントのHTMLへ置換されます。 フラグメントでは、HTML,CSS,JSを取得するPATHをJSON形式で返却するようにします。 JSONを返すURLは、/manifest.json と統一しています。
このような構成を取ることで、担当領域を分割することができます。 例えば、フラグメントAとページXをチーム1が管理し、フラグメントB、C、ページYをチーム2が管理するなどです。
また、RustのWebAssemblyを下記のようなテンプレートで組み込むことができます。
特定の重い処理をRustのWebAssemblyで処理するようなフラグメントをページに混ぜることができます。
構築して困ったこと
同一ドメイン内でのEdge Workers通信が不可
Cloudflare Workersは、任意のドメインで動かすことになります。 例えば、ドメインA内に複数のCloudflare Workers XとYがあったとすると、 XからYへの通信ができないです。
https://community.cloudflare.com/t/issue-with-worker-to-worker-https-request/94472/37community.cloudflare.com
そのため、複数のCloudflare Workersを使用する場合は 複数のドメインが必要になります。 先程の例なら、ドメインAに属するCloudflare Workers XからドメインBに属するCloudflare Workers Yへ通信することができます。 私は、freenomのtkドメイン(無料)を複数購入しました。
直接IPアドレスへリクエストできない
ローカル開発時に困ったことがあります。 Cloudflare Workersをローカル開発する場合、wrangler:dev というコマンドで検証します。 検証中に、他のCloudflare WorkersのURL(localhost:XXXX)へアクセスしようとしても、直接IPとなるため失敗します。
https://support.cloudflare.com/hc/ja/articles/360029779472-Cloudflare-1XX-%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0#error1003support.cloudflare.com
そのため、下記のようなサービスを使って、私は解決させました。
Cloudflare Workersによる制約が大きい
Cloudflareのプラットフォーム上では、下記のランタイムAPIが使用できます。
Cloudflare Workersの仕組みを把握していないのですが、この提供されているAPI以外は、 確か使えなかったような気がします。
最後に
Edgeって、私の印象では、単なる静的コンテンツを置くだけのものと考えていました。 それが、動的なコンテンツ、つまりEdge Workersのような存在を知り、Edgeの世界が広がったように感じます。 Webアプリケーションを、よりユーザーに近いEdgeへ配置するようにすれば、レスポンス速度改善が期待できます。
Micro Frontendsというより、Edge Workersの話が多かったですね。(笑)
20代後半エンジニアである私がこれから学ぶべきこと
私は、現在26歳のWebエンジニアです。これまでの技術に対する学び方と、これからの技術に対する学び方について、少し考えたいと思っています。
これまでの20代前半
新卒入社した当時の私は、業務上、PHP + MySQL on AWS の組み合わせでWebアプリケーション開発を学んでいました。 それとは別に、プライベートでは、Node.js + MongoDB on SAKURA レンタルサーバでWebアプリケーション開発もしていました。
当時、Webアプリケーション開発のフロントエンドとバックエンドをなんとなく動かせる程度で満足していたのですが、 先輩や同僚のエンジニアや、お勧めされた書籍から影響を受け、あらゆるものに興味を示しました。
- SQLや正規表現、文字コードといったエンジニアにとって欠かせない技術
- sedやawk, make といったshellscriptの扱い方
- 手続き型、オブジェクト指向、関数型といった考え方のパラダイムシフトを発生するような考え方
- MVC, MVVM, CleanArchtecture などのアプリケーション設計
- ユニットテストやE2Eテストなどを使ったTDD開発
- CI/CD を活用したDevOps開発
- インフラやミドルウェアの自動構築
- CloudNativeなアプリケーション開発
- SSRやSPA、SEOといったWeb設計
- インタプリタ言語やコンパイラ言語
- コンポーネントベースのフロントエンド開発
- Webゲーム開発
- ビッグデータを扱う技術
- 様々なクラウドサービス技術
- 強化学習
- Bot開発やスクレイプ技術、GASなどの業務改善
Webアプリケーションに関する幅広い領域をあらゆる角度で学んでいったのかなと思います。
これからの20代後半
これからも、興味を持った分野を見つけて、手あたり次第学んでいくのも1つのキャリアだと思います。 ただ、自信過剰という訳じゃないですが、多分やればある程度できるようになれると自負しています。
しかし、私としては、そろそろ広く浅くから、狭く深く学ぶ領域(専門性)を見つけたいと思っています。 どういった領域を突き詰めたいか、考える時がきたのかもしれません。
何を突き詰めたいか
単純にソフトウェア技術を突き詰め、テックリードを目指すか、 プロジェクトマネージャーやエンジニアリングマネージャーといった管理職を目指すか。 それでいうと、前者を目指したい。具体的には、Webに関わる専門性を突き詰めたいなと。 また、アーキテクトのような職業に憧れています。
VueやReactなど言語は違えど、Webアプリケーションの成果物はそう変わりません。 だとすると、あまり似たようなベクトルの言語を学んだところで、面白みが薄いのではと思っています。
それよりも、どのレイヤーにどういう役割を持たせるか、クラスをどのように設計するか、レスポンス速度をより早くするためにはどのようなシステム構成にすべきなのか、そういった視点を考える方が楽しいと最近感じています。
また、アーキテクト的な視点以外に、WebのNative(標準)部分の話やブラウザの話、W3Cの動向など、これからのWebについてキャッチアップし続けることにも、力を注ぎたいと思っています。
それらを踏まえると、『Webの専門性が高いアーキテクト』のような立ち位置を目指したいと思います。
最後に
ポエムみたいな話になってしまいました。以上、最近の悩み事でした。
技術におけるアンテナの張り方 (巨人の肩に乗れ!)
Photo by JESHOOTS.COM on Unsplash
エンジニアは、普段様々なところから技術をキャッチアップすると思います。それは、SNSであったり、ブログであったり、動画であったりです。 そこで、私の技術をキャッチアップするためのアンテナの張り方について、紹介しようと思います。
RSS
RSSは、良いです。不定期にお気に入りの企業やサービスのテクニカルな情報を知ることができます。 特に、大手の企業のブログや、自分自身の関心を持っているサービスのRSSがオススメです。
Tech Blog
- airbnb-engineering
- blog.twitter.com
- eng.uber.com
- engineering.atspotify.com
- engineering.fb.com
- engineering.linkedin.com
- github.blog
- instagram-engineering.com
- medium.engineering
- netflixtechblog.com
- slack.engineering
Web
- blog.chromium.org
- blog.google/products/chrome
- blog.whatwg.org
- discourse.wicg.io/latest
- discourse.wicg.io/posts
- tools.ietf.org
- www.w3.org
CDN
BBS
Book
News
Twitterの公式アカウントをフォローするのも良いです。 また、特定分野に長けているエンジニアの方であったり、コミュリティアカウントもフォローすると良いでしょう。
例えば、私の場合は、次のアカウントをフォローしていたりします。
- Michael Geers (@naltatis) / Twitter
- Micro Frontends in Action の著者
- 勉強会スライドbot (@tech_slideshare) / Twitter
- 日本における勉強会のスライド収集 Bot
- Web Incubator CG (@wicg_) / Twitter
- Web Incubator のコミュニティ
UseCotlin
私の独自ツールです。TwitterAPIを使って、SpeakerdeckやGoogleSlidesなどの技術スライドをSpreadsheetに収集しています。 勉強会やカンファレンスが開催されると、Twitterで宣伝されることが多いため、こちらのツールで自動的にキャッチアップできます。 また、日本だけではなく、世界各国のプレゼンテーションを知ることができます。
Medium
Mediumの有料会員です。Mediumは、Tech系の質の高い投稿が多く充実できます。 無料会員だと、一日の閲覧回数に制限があるため、ちょっとストレスに感じ、有料会員になりました。
Hatena Blog
今日のホットエントリを見て、何が流行りなのか、どういう分野に関心があるのかざっとななめ読みしています。
また、テクノロジだけではなく、総合分野を見ていたりします。
最後に
このネタを思いついたので、勢いで投稿してみました。 もしどなたかの参考になれば、幸いです。