テクノロジー＆エンジニアリングセンターの伊藤です。

会津若松のAiCTで働き出して2度目の冬を迎えようとしています。 豪雪として知られる会津ですがここ2年は暖冬で雪がほぼ積もっていません。 昨年より寒く感じるためでしょうか、今年は雪が降るのでは？というのが大方の予想です。 雪が積もると雪かきが毎朝の日課となりとても大変な作業になりますが、そんな雪かきを前向きに捉えてジョセササイズと言うらしいです。 「除雪でエクササイズ」を略してジョセササイズです。冬は運動不足になりがちなので雪が降ったらジョセササイズに励みたいと思います。

さて、今回のブログでは会津大生向けに開催したSPA(React)とAPI(Nablarch)のハンズオンについてお話ししたいと思います。

会津大生向けにハンズオンを開催したいきさつは？

普段はNablarchの開発やサポートをしているので地元会津に直接関係する仕事をしていません。 何か地元会津に関係する仕事ができないかと考えていた時、会津大学復興支援センターが実施しているICT人材育成事業において会津大生を対象に実践的なアプリ開発を教える機会があり、今回の勉強会を開催することとなりました。

勉強会の開催にあたって考えたことは次の2点です。

  • 勉強会をやったら終わりではなく次に続くようにしたい（点でなく線にしたい）
  • 近い将来に役立つようにしたい（今後学生が活用できるものにしたい）

ちょうど社内でサービス開発を推進するための施策を進めていて、SPA＋REST API、モバイルアプリ、DevOpsといった技術要素を扱っていました。 こうしたサービス開発のベースとなるアプリ開発やDevOpsを学生が学ぶことで、学生自らがプロダクトやサービス作りにチャレンジしやすくなるのではと思い「サービス開発エンジニア体験」を企画しました。 ハンズオンで技術要素を体験し、最後に学んだことを活かす場としてハッカソンを開催します。

ハンズオンやハッカソンは各技術施策の担当チームにサポートしてもらいながら準備・実施をしています。 「会津大生に向けて勉強会やるから協力して」とSlackで各チームに呼びかけると「面白そうだね」と言ってすぐに協力してくれました。 どのチームも上記のスケジュールに合わせて計画してくれたり、ハンズオン当日にリモートで参加してくれるなど、各チームのサポートにとても感謝しています。 各チームは東京や大阪を拠点としていますが、SlackやZoomで気軽に相談に乗ってくれるのでとても心強いです。

すでに開催したSPAハンズオンとAPIハンズオンの内容を簡単に紹介します。 SPAハンズオンとAPIハンズオンはFintanで公開しているSPA + REST API構成のサービス開発リファレンスをベースに作成しています。 SPA + REST API構成のサービス開発リファレンスのハンズオンは個人で学習できるようになっていますのでご興味がある方はぜひご覧ください。

SPAハンズオンの内容は？


掲載元URL　https://speakerdeck.com/aizurage/spahanzuon-on-20201002

Reactを使ったSPAの作り方を学ぶハンズオンです。

題材はよくあるToDo管理ですが、ToDoを管理するページだけではなく、Welcome、ユーザ登録、ログインといったユーザ認証のページが含まれているため、ルーティング（ページ遷移）のやり方を学べます。 さらに、ユーザ登録やログインでは入力値のバリデーションが含まれているので、ハンズオンで学んだルーティングとバリデーションを使うことでフォーム入力を伴う機能を作れるようになります。

SPAを作る時に困るのがバックエンドとなるAPIを用意しないと開発が進めにくい点です。 このハンズオンではOpenAPIドキュメントを活用し、APIを呼び出すためのクライアントコードの作成やダミーデータを返すモックサーバの準備など、実際の開発の困りごとを解消する方法も含まれています。

Reactを使ったSPAの作り方を素早く学ぶのに最適な分量のハンズオンだと思います。 このハンズオンに興味を持った方はSPA + REST API構成のサービス開発リファレンスをご覧ください。

APIハンズオンの内容は？


掲載元URL　https://speakerdeck.com/aizurage/apihanzuon-on-20201121

先ほどSPAでお話ししたToDo管理のバックエンドとなるREST APIの作り方を学ぶハンズオンです。 REST APIの作成にはNablarchのRESTfulウェブサービスを使います。

REST APIの作り方なので、RESTの説明があってフレームワークを使ったRESTの実装方法の説明になると思われますが、このハンズオンではそれらオーソドックスな説明に加えて、アプリケーションのアーキテクチャに関わる話も含んでいます。 ToDo管理を行うAPIではアプリの中心となるドメインロジックを扱うため複雑になるところなので、レイヤードアーキテクチャ、値オブジェクト、イミュータブルを活用してドメインモデルを使って実装しています。 一方、ユーザ認証を行うAPIでは複雑なドメインロジックを扱う必要がないためドメインモデルを使わず、サービス層を切り出すだけでシンプルな構成で実装しています。 ドメインモデルを使う場合と使わない場合の実装を比較できるのでREST APIを作る際のアーキテクチャの参考になると思います。

また、Nablarchの特徴でもあるのですが、REST APIのテスト自動化について学べます。 Nablarchではアプリをテストするためのテスティングフレームワーク（JUnitベース）を提供していて、テストコードを書いて実行すると、アプリを起動しリクエスト/レスポンスを行い、処理結果のアサートを行えます。 そのテストの中でOpenAPIドキュメントに定義したレスポンスの型と、実際のレスポンスの型が一致しているかの検証方法も含んでいます。 OpenAPIドキュメントにより、フロントエンドとREST APIの認識を合わせているため、この検証は実際の開発現場ではとても重要になります。

このハンズオンに興味を持った方はSPA + REST API構成のサービス開発リファレンスをご覧ください。

アンケートの結果は？

学部1年から修士2年まで幅広い層の学生に参加頂きました。 一番の目的である「役に立つか？」という質問では半数以上の方が役に立つと回答頂けたので微力ながら学生に刺激を与えられたかと思います。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。