Back
Featured image of post 個人的な2022年のロードマップ

個人的な2022年のロードマップ

このブログを書き始めてから、今年で4年目となります。振り返ってみるとブログを書き始めた頃はSEとして主にSIerの基盤チームの仕事をしていたので、インフラやライブラリを含めさまざまな技術に触れることが多かったのですが、去年に転職をして本格的に業務系エンジニアとしてバックエンドを担当することになり触れる技術や興味などにも変化があったかなと思います。なので、今回は振り返りを兼ねて今年のロードマップに関して少し述べたいと思います。

過去分のポストを振り返ってみると最初は主にJava、Spring、Linux、Jenkinsなどに関するものが多かったのですが、最近はやはりKotlinで使えるさまざまなフレームワークなどに興味が移っている感覚です。基本的にJavaでもKotlinでもJVM言語であることは同じなのでできることや分野は大差なく、転職してからも使っているフレームワークはSpringなのですが、Kotlinの開発元であるJetBrains社がいろいろなフレームワークを開発しているのもあり自然にそれらに興味を持つようになっていますね。

Sophomore jinxを克服する

Sophomore jinxは日本語で「2年目のジンクス」といわれている言葉です。大学2年目になると新入生だった頃と比べ、成績が下がり熱意が消えるというということを指す言葉らしいです。これの意味を拡張して、1年目に新人王などに選ばれた選手がその次の年からは成績が悪化したり、人気の映画の続編が面白くなかったりする場合など最初より何か劣化した場合を指すことになっているとか。

自分の場合はエンジニアになってから4年目になるのですが、確かに2年目からは1年目の時と比べ熱意はなくなっている気がします。だからと言って新しい技術に興味がなくなったり、プログラミング自体が飽きたという訳ではありませんが、前はやりたいことがあったらずっとモニタと睨めっこしながら徹夜でコードを書いたりしていたのに、今はとてもそういう気にならないというのが違うところですね。年を取ったためかとも思いますが、

これについては自己分析とやりたいこと、そしてできることを冷静に整理して少しづつでも何か成果物を出せるようにしないと思っています。去年もそうでしたが、このようなポストを書くのはそのためでもあります。計画しているもの全てを成せるとは思いませんが、多くの目標の一部でも達成した方が最初から少ない数の目標を立てるよりは良いのかなという気がしています。なので、まずは「やるかどうかわからないけどアンテナは張っておく」という感覚でいろいろな技術に目を通しておこうかなと思っています。

Frontend

私はJavaScriptとTypeScriptの基礎を研修やUdemyの講座で学んだくらいのレベルで、フロントエンドの仕事をあまりやることがなかったです。しかし、昨今のウェブアプリの開発においてのトレンドをみるとやはりフロントエンドの技術を一つは学んでおいた方が良さげな気もしますし、バックエンドの役割を吸収しているような気配すらするなという気がしますね。何より、エンドユーザにとって画面のないアプリは想像できないので、今まで自分が使うためのAPIやライブラリ、コマンドラインアプリだけでなく本格的にGUIを活用した何かを作ってみるべき時が来たかなと思っています。

何よりフロントエンドの場合、数年前はいろいろなライブラリとフレームワークが存在してどれを使った方がいいか全くわからない状況でしたが、最近は3強だといわれていた中でもAngularを抜いたReactとVueのみが生き残り、さらにそれらを基盤にしたフレームワークが登場するなど、そろそろ技術の成熟期と言ってもいい時代になったのではないかと思いますので、React基盤のNext.jsか、Vue基盤のNuxt.jsのどちらかを選べばよい時期なのではと思います。私自身も今年はそのうちのどちらかに触れてみたいなと思っています。

せっかくなのでNestJSのようなJavaScript用のサーバサイドフレームワークにも触れてみるのは良いかも知れませんが、サーバサイドというバックグラウンドがある自分にとってはまずはフロントエンドのみでちょうどよいチャレンジかなと思ったりもします。後述しますが、バックエンドではまた別に触ってみたいものもありますのでなおさらですね。

Quarkus

個人的にはSpringを長く使っていたので、新しいフレームワークを使ってみたいという願望があります。一つのフレームワークに慣れると、それを使い続けるのも選択肢としては悪くないと思いますが、新しい技術にはメリットもデメリットもあるものなので、少なくとも触れてみる必要はあるかなと思います。なので去年はQuarkusKtorの二つを触ってみました。

個人的にはJetBrainsのプロダクトに信用を持っていて、Kotlin向けという点でもKtorは悪くなかったと思ったのですが、機能が不十分であるところや、アーキテクチャで悩ましいところがあるという面で躊躇しています。一方でQuarkusはネイティブにコンパイルでき、Springのライブラリを一部そのまま使えたり、そもそもSpringとあまり変わらない感覚でコードをサクサク書けそうなイメージなので本格的に使用してみたいと思っています。最大の問題はやはり、ネイティブの場合ビルドにかなり時間がかかるということですが、これはCIとの連携をうまくやっていくしかないかも知れませんね。

FastAPI

いきなりPythonになりますが、FastAPIにも触れてみたいと思っています。以前から違う分野に転職をするとしてもバックエンドはやり続く可能性が高いと思い、いろいろな言語とフレームワークを触ってみたいと思っていました。その候補としてはExpressRocketVaporなどがあって、これらを全部触ってみた後、最も自分の好みに合ったものをプライベートで使い続けようと思っていたのです。

そんな中、Pythonは普段もたまに簡単な自動化のスクリプトを作るなどの目的で使っているので、Djangoを触ってみようかと思っていたところ、最近はFastAPIで爆速の開発ができるという話を聞いて興味を持つようになりました。今もKotlinとSpringで開発はできますが、シンプルなプロジェクトならこういった軽いオプションが一つあっても悪くなさそうな気がします。インタープリタ言語なので起動も早く、Techempowerのベンチマークでも意外と悪くないパフォーマンスを見せてくれているのも魅力的ですが、SwaggerReDocによるドキュメンテーションが自動で行われるというところがかなり良さげです。なんでもサクッと作れそうな感じがしますね。

また、直接使わないとしてもコードが綺麗で勉強になる噂を聞いているので、少なくとも一度はコードを読んでみたくなります。

SwiftUI and Jetpack Compose

個人的に本当にやりたかった分野は、GUIを持つアプリを作り上げることです。エンジニアという職業を持つ前から作ったのもJavaFXによるデスクトップアプリでしたので。最近はJavaScriptだけでもElectronReact Nativeなどを使ってなんでもできるという時代にはなっていますが、せっかくJavaとKotlinができるようになったので、ネイティブアプリを作ってみた方が良さそうな気がします。

以前Flutterが発表されてまもない時期に、一度React Nativeと一緒にチュートリアルだけ触れてみたことがあるのですが、当時にもFlutterのいわゆる「宣言型GUI」というものに魅力を感じていたのでこれからモバイルをやるとしたらFlutterかなと悩んでいました。最近はモバイルだけでなく、デスクトップアプリやウェブアプリまで作れるようになったのでなおさらでしたね。

しかし、SwiftUIJetpack Composeというものが登場してからは完全にこちらに傾きました。どうしても同時にマルチプラットフォームアプリが開発できるという面ではFlutterが有利だとは思いますが、それと似たような感覚でネイティブのUIが作れられるようになったのでもう悩む必要がないかなという気がします。

特に、SwiftUIだとMac用のデスクトップアプリを作ることもできますが、Jetpack Composeならデスクトップアプリだけでなくウェブアプリも作ることができて、さらにKotlin Multiplatform Mobileを使うとビジネスロジックの共有ができるようになるのでこちらの方が自分の場合にはより合うのではないかという気がしています。自分に合うというのは、私がめんどくさがり屋なので一つの言語で全てを解決したいという願望を持っているというだけの話ですが…とにかく一度使ってみて、よかったらフロントエンドでもJetpack Composeを使ってみるのはありかなと思っています。Kotlin/JSという選択肢もありますが、こちらはまた次の機会で。

ただこれらのデメリットは、やはりどれもまだ完成されてない技術ということですね。分野を問わず新しい技術のジレンマでもありますが、新技術がどれだけ良くてもそれだけでは完全ではない(もしくはかなり不便)という場面が出てくる可能性があるので、当面は少し様子を見ながらシンプルなアプリを作ってみることから初めてみようと思います。Flutterという良い先例があるので、良さげな機能はすぐに吸収してくれるという期待もあります。

Oracle Cloud

他のクラウドと比べかなり後発したためか、無料プランでもメモリ1GBのVMインスタンスを二つも提供するという破格の政策で知られたOracle Clouですが、2021年からはさらに選べるVMインスタンスにARM(Ampere A1というオプションを追加しています。

Ampereが既存のAMDやIntel製CPUを使うインスタンスと比べて目立つのはやはり性能です。ARMだと互換性の問題がありx86と比べ利用率が下がると思ったためか、無料プランでも4つのOCPU、24GBのメモリという良い性能のインスタンスを提供しています。無料のインスタンスを2つまで作ることができるので、2つのOCPUと12GBのメモリという構成を2つのインスタンスに分けて指定することもできます。

個人的には既存の無料で使えるインスタンスが1つのOCPU、1GBのメモリというオプションだったので、Javaアプリのビルドなどヘビーな作業には向いてないのが惜しいところでした。なのでMattermostのサーバとして使うなど軽い感じでしか使い道がなかったのですが、Ampereの導入でCI用サーバなどに使える道もできたかなと思います。Oracle Cloudのホームページで紹介していること以外でも、他のベンチマークを参照するとCPU性能は期待しても良さそうな気がします。無料でOracle DBも提供されているのでそちらを使うか、それともVMインスタンスを一つDB用に使うか、GCPやAWSの無料サービスと組み合わせて使うとかでも色々できそうな気がします。

ただ、やはり互換性が気になっていたのですが、個人的にはApple Silicon搭載Macを使ってみながら「意外と悪くない」という結論に至っています。プログラミング言語などはすでにARM対応済みのものが多く、サーバで使うとしたらFFmpegImageMagickGraphicsMagickなどを使うケースもあるかなと思いますが、どれもARMバージョンをインストールもしくはビルドできるので特に問題はなさそうです。

他に問題なら、今の所VMインスタンスを作ろうとしてもハードウェアが十分ではないのか、2つのOCPU以上のスペックでは作れないというのが問題ですね。時間が解決してくれる問題かも知れませんが、いつになったらインスタンスを自由に作れるかわからないというのは確かに問題と言えるでしょう。

最後に

意欲がないといいつつ、これだけやってみたいものが多いというのはまだ自分がエンジニアとして気持ちが死んでいるわけではないからよかったなと思わせます。本当は意欲がないというより「面倒臭いだけ」と訂正するべきかもですね…

というわけで、色々とやりたいことだけを並べてみましたが、今年はそろそろ何か実際使えるアプリを作り出すのを第一の目標にしたいと思っています。何か作ってみるだけでも間違いなく良い経験、良い経歴になるはずなので。

では、また!

Built with Hugo
Theme Stack designed by Jimmy