こんにちは高知からリモートインターンしている森田ドラゴンです。もう21日もインターンさせて頂いているんですけど、半分くらいは8月に入ってからのカウントです。今日は、インターンの振り返りと、次の課題決めを行いました。

振り返り 1~ 20日

上が今までのインターンで行った内容です。最初の方のEC2のあたりは、自分で使って遊ぶこともあったのでサクサク進んだ覚えがあります。一方SAMやCloudFormationのあたりはかなり苦戦してました。今でも苦手意識はあるんですけど、SAMの値でわからなかったところを、森さんから聞くことができたので、次はもう少し早くできると思います。

今までのインターンで、色々なドキュメントを読む力をつけられました。逆に、質問をしない悪い癖があるので、これからは３時間おきぐらいに経過報告をすることにします。うっかり忘れないようにアラームもかけて起きます。

設計やテストを経験したい、swaggerが触りたいと希望を出したところ、森さんから次の課題を出してもらいました。ありがとうございます。

ドラゴン天気予報サイトを作る
- Web画面とする
- 入力は、日付と都市名
- APIを自前で用意し、そこでデータを収集
- 画面でその都市の入力された日付のお天気を可愛く表示
作業としては
- 設計
- 製造
- テスト を行うこと

可愛く表示すると言うところが一番の難所かもしれません。

お天気API

画面設計

どの程度、画面設計に書くべきか迷いましたが、フロントでやろうと思っていることをとりあえず書き出して見ました。ちなみにお天気APIと言っても、天気を収集する方ではなく、天気を収集しているAPIにデータを渡して、レスポンスを整形して返すAPIになります。今回はどれだけ使っても利用が無料の、livedoorお天気APIを使用することにしました。

処理概要仕様書

次は処理概要仕様書です。どの処理をAPIに担当させるか、jsに担当させるか迷いましたが、結局下の形に落ち着きました。最初は画像をS3からとって来て表示させようかとも思いましたが、連携させる必要もないので、API側で処理することにしました。表示させる天気の項目が増えると、jsとAPI両方修正するひつヨグアあるからです。

処理詳細仕様書

詳細、といっても僕はSwaggerの仕様に明るくないので、ここで詰まってしまいました。(さっそく報告し忘れました)とりあえず、自分がわかるフロントとjsの範囲の処理詳細仕様書だけ、次の時間に書きたいと思います。

感想

今気づきましたが、API GWの処理も書かないとダメですね。APIをやりたいなーと思っていたのは、SAMのテンプレートで毎回出力されるからです。SAMの中のAPI GWのパラメータを見ていると、面倒くさいなーとも思いますが、色々なパラメータが一つのリソースを作るところを想像すると、ちょっとドキドキします。それと、よくAPIはウェイターだ、なんて話を聞いたりしているので、憧れてました。次はフロントをサクッとかいて進めたいと思います。