2020年の振り返り。結婚と継続力
2020年も、もう残りわずかになりました。今年の振り返りをはじめてブログに残そうと思います。
技術
UseCotlin
2020年3月より、自前で作ったツール Cotlin で技術キャッチアップをはじめました。このツールは、Twitterに投稿された技術資料(ex.speakerdeck,slideshare)を収集するだけのツールです。日本だと、技術勉強会の資料はTwitterで投稿する習慣が（私の観測範囲では）あるため 、この習慣を利用して、様々な技術資料を広く発見できることができます。
下記のスプレッドシートに、技術資料リンクを自動登録しています。
日本だけじゃなく、海外の技術資料も発見できるので、色々な観点の技術を知ることができました。例えば、テスト手法、アーキテクチャの考え方、働き方の考え方などです。これを毎日欠かさずキャッチアップし続けていました。
Github Contribution
UseCotlinは、主に技術のインプットばかりで、アウトプットができていません。インプットのし過ぎで、頭でっかちにならないよう、毎日アウトプットを心がけていました。
ほぼ毎日、contributeするようにしました。InputとOutputのバランスは難しいですが、取り組んで良かったです。
Twitter Follower
（思いつきで）Twitterのフォロワーを増やしてみようと思い、TwitterのFollowerを自動的に増やす仕組みを構築しました。2020年9月ぐらいからはじめて、フォロワー1000人ぐらいだったものがもうすぐ3000人ぐらいになります。
手作り即席Twitter自動フォローGASを稼働し始めて、約3週間。非常に伸びが良い。 pic.twitter.com/ZdjwsQQeni
— silverbirder (@silver_birder) 2020年10月21日
生活
結婚
11月22日、26歳で、はじめて結婚しました。 奥さんは、大学時代からお付き合いしていた人で、一度別れたりと紆余曲折ありましたが、私の方からプロポーズしまして、結婚することになりました。仕事を早く終わらせて、プライベートがとても充実しています。
在宅勤務とIoT
コロナの影響で、在宅勤務が当たり前になりました。今年買ったIoTで良かったものを紹介します。
- スマートエナジーハブ Nature Remo E lite
- 家の電力使用量をリアルタイムに可視化
- NETATMO ウェザーステーション
- 家の室温、湿度、Co2をリアルタイムに可視化
- Arlo カメラ
- 玄関前やベランダをカメラで可視化
- Withings Sleep&体重計
- 睡眠時間や体重を計測し、スマホからデータを可視化
来年の抱負
これまでは、技術をガンガンキャッチアップしていましたが、2021年は、技術とプライベートのバランスを取ろうと思います。
終わりに
コロナコロナと、今年は騒ぎ立てていましたが、来年はもっと楽しい話題で盛り上がりたいなと思います。
コロナ禍におけるエンジニアのための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の専門性が高いアーキテクト』のような立ち位置を目指したいと思います。
最後に
ポエムみたいな話になってしまいました。以上、最近の悩み事でした。
