[N予備校プログラミングコース] 第4章 各種フレームワーク / 外部認証 / CI / 通信

第3章を受講し終えて、その後造血幹細胞移植やら発熱やらでなかなか体調が優れず、また身体を起こすための体力が続かなくて全く進められていなかったN予備校プログラミングコースだが、ようやく元気になってきたので再開した。
第4章は「実践サーバーサイドプログラミング」。
いよいよプログラミング入門も佳境に入ってきた感じだ。

第4章ではまず Node.js 用の各種フレームワーク、外部認証、CI、さらに Ajax や WebSocket といった通信を学習する。

Express、外部認証

まずは Web フレームワーク。
ここでは Express を学習する。
Node.js 用はもちろん、他言語の Web フレームワークも使ったことが殆ど無いので、他と比べてどうこうというのは分からない。
何となくの印象では、Ruby on Rails や Django 等、大規模な Web やソシャゲ案件でも使われるそれに比べて、軽量且つとっつきやすい気がする。
ホントに何となくなので、実際のところは分からないが。
ただ HTML テンプレートの pug はイマイチしっくりこない感。
慣れの問題だろうか。

Express では様々な npm モジュールをインストールして使用することができるが、外部認証もその一つだ。
第3章で Basic 認証は学習したが、やはり今どきの Web アプリは外部認証は必須だろう。
ここでは、passport 及び passport-github というモジュールをインストールし、GitHub の認証を利用してログインできる機能の実装を学習した。
passport は他にも Facebook / Twitter / Google 等様々なサービスの外部認証を組み込めるので、非常に便利だ。

Web に限ったことではないが、フレームワークの選定においては、こういった外部モジュールが充実しており、且つ容易に組み込んで利用できるか、というのも大事な点だ。
そういった意味では、Express はよくできていると思う。
いや、Express というよりは Node.js なのかな。

mocha、CircleCI

テスティングフレームワークは mocha を学習。
実を言うと、これまで20年以上プログラマをやってきているが、ちゃんとした形でテストというものを書いたことは殆ど無い。
昔から興味はあったのだが、昔のコンシューマゲーム業界なんてテストっていう概念自体無かったし(無かったよね?)、その後移った組込み業界でも、少なくとも自分が入るPJではユニットテストは皆無、結合テストもちゃんとやってそうなPJはあまり無かった。(さすがに総合/システムテストはあった)
フリーランス転向後に来たソーシャルゲーム業界では、サーバー側は皆当たり前のようにユニットテストを行っていたが、自分が担当していたクライアント側ではユニットテストをやっているPJは皆無だった。
まあソシャゲの場合、MVC でいうところの View みたいなもので、UI 周りってアニメーションやら操作が絡むから、自動テスト的なものが作りづらいってのもあるが。
なので、自分の中では未だにテストを書くという習慣も動機も無かったりする。
さすがにこれからのご時世、それもどうかと思うので、いい加減身につけたいものだ。

また、テストとなると、やはり commit & push する度に毎回テストを自動的に行う、いわゆる継続的インテグレーション(CI)環境の構築が必要だ。
今回は CircleCI というCI環境上で、上記のテスティングフレームワークを使用して書いたテストの自動実行を学習した。
CI自体は、ソシャゲ業界では当たり前のように導入されていたし、クライアント側でもテストは無くとも自動ビルドはやってたので、考え方自体は知っていた。
ただ、自分でCI環境を構築したことはなく、誰かがお膳立てしてくれた環境に乗っかってただけだ。
コンシューマゲーム業界でもローカルサーバに Jenkins を導入して自動ビルドするってのは当たり前になってきている(はずな)ので、そろそろ自分でもそういった環境を構築できるようになっておきたいところだ。
もっともコンシューマゲーム業界の場合、ビルド環境はほぼ Windows 一択なので、ライセンス周りでいろいろ面倒だったりするが難点だが。

webpack

続いて webpack
webpack はモジュールバンドラーという、自分が書いた .js ファイルや、それが参照しているライブラリの .js ファイル、.css 及びそれが参照している画像ファイル等を bundle.js という一つのファイルにまとめてくれるツール。
これによってクライアントサイド(HTML で読み込まれる)の JavaScript も Node.js を使用できるようになるそうだ。
クライアントもサーバも同じライブラリを使用できるのは便利だが、その代わりクライアントサイドの .js や .css をどこか書き換える度に毎回 webpack を実行しなければならないので、痛し痒しだ。
C/C++等のコンパイラ型言語でビルドして実行ファイル作ってるようなものだと思えば、大した違いはないが。

jQuery

そしてDOM操作はWeb系ではお馴染み(?)の jQuery
Node.js 環境においては、jQuery も npm でインストール及びバージョン管理ができるのは便利だ。
jQuery は5年ほど前に Web アプリの習作としてタイムゾーン変換アプリを作ったときに触ったことはあるが、jQuery のオブジェクト変数が「$」で始まるのは違和感を感じる。
(必ずしも $ でなくても良いようだが、慣習として jQuery のオブジェクトは $ 変数に入れるようだ)
そういえば JS のライブラリやフレームワークは数年レベルであっという間に廃れる印象があるが、jQuery は2006年リリースなので、結構息が長い。
何のかんの言われつつも、10年以上使われているということは、それだけ良いものだということなのだろう。

AJAX、WebSocket

一通りフレームワークを学習した後は、AJAX 及び WebSocket によるクライアント〜サーバ間の通信周りを学習。
シングルページアプリケーション(SPA)を作る際は AJAX は基本中の基本だし、またチャットやゲーム等ある程度リアルタイム性を求められるアプリは WebSocket が有効だ。
名前や概要は何となく知ってはいたものの、やはり百聞は一見に如かずだし、さらには自分で実装して動かしてみると、その理解度はまるで違うと感じる。

なお AJAX の場合、サーバ側は Express、クライアント側は jQuery で実装すればよく、クライアントが必要な時にサーバにデータを要求し、データが送られてきたらそれを使って画面を更新する、いわゆるプル型による実装となる。
それに対して WebSocket の場合、サーバからクライアントにデータを送り、クライアントはそれをイベントで検知したら、送られてきたデータを使って画面を更新する、いわゆるプッシュ型による実装となり、その実現のために Socket.IO というライブラリを npm でインストールする必要がある。
とはいえ、実装してみるとそれほど手間ではなく、むしろこんな簡単にプッシュ型の Web アプリを実現できるとは思わなかった。

成果物

これまでの学習による成果物。
nyobi4.gif
ログインは GitHub による外部認証、四角形の拡大縮小及び移動は jQuery によるアニメーション、サーバーステータスはサーバから WebSocket によってプッシュされてくるロードアベレージをイベント発生の度に更新している。

実践編となり、急激に技術範囲が広がってきた感がある。
Web 系は技術の流行り廃りが激しい印象があるが、これだけの範囲をカバーしつつ、常に最新の情報を追いかけていくのは非常に大変だ。
ここで学習した内容も、5年後には大きく変わっている可能性がある。
今のところ Web 系のエンジニアになる予定はないが、それも今後の需要次第では嫌でも Web 系中心でやっていかざるを得ないかも知れない。
そうなった時、この速度感に自分は果たしてついていけてるのだろうか、という一抹の不安を感じる。
もちろん、事前に勉強していればある程度は何とかなる、という自信もあるが、目の前の業務をこなすだけでいっぱいいっぱいになってしまうと厳しい。
今どき、これから勉強するのでちょっと待っててください、なんてのが通用するわけないのだから。
我々おっさん世代エンジニアとしては、やはりそこら辺をバランスよくできるようにならなければいけないだろう。
まぁ実際のところ、新しい技術を学ぶのはすごく面白いと感じているので、そう思えているうちは大丈夫かな、と楽観的に考えてはいるが。

さてこの後だが、データベースについて学習した後、いよいよ集大成となる Web サービスの開発となるようだ。
データベース自体はソシャゲで SQLite はそこそこ触ったりしたが、ちゃんと学習したことはないので、いい機会だ。

そしてその後は、これまで学習したことのおさらいも兼ねて、何かしら自分でサービスを作ってみたい。
できることならリアルタイム性のあるカジュアルゲームでも作りたいところだが、企画とか素材をどうするかが悩ましいところだ。
少なくともあと数ヶ月、時間だけはたっぷり確保できるので、ゆっくり考えてみよう。

この記事へのコメント