どっかのチラシの裏

技術的な記事を書いたり書かなかったりします。

個人開発webアプリケーションの方針の転換

紆余曲折あり、「Rails + フロントの一部にVue.js使用。開発環境構築にDockerを使う」から「React + Django REST Framework を使ったSPAをDockerを使った開発からAWS ECSへのデプロイを実践する」という大きすぎる方針転換をしたため、手順を迷わないためにメモ。

方針

考案当初はECSでデプロイを行うためにNginxコンテナも作り、開発環境から本番環境に近い環境で行こうと考えていたが、調査の結果、現段階で「ReactもDjangoも全くの初挑戦」、「以前RailsのwebアプリはEC2でデプロイしたが、ECSでのコンテナ活用した本番デプロイは全くの初挑戦」、「フロント/バックを完全分離したSPAアプリは全くの初挑戦」という三重苦となっているため、一つずつ分割して順番に挑戦することにした。

具体的な手順

  1. Docker, docker-composeを使い、ローカル開発環境でReact、DRFを用いた個人開発アプリを開発(Nginxなどのwebサーバのことはとりあえず置いておく。実際、Dockerを使わないReactとDRFの開発の勉強は十分にできている)
    • アジャイル開発の観点から本来は「最初からアプリの基盤をECSでデプロイして雛形はどちらも稼働可能にしておく。それから開発をはじめて逐次デプロイをしてmainブランチはリリース可能に保つ」というのがセオリーだと承知しているが、上述した三重苦のため、泣く泣くそれは諦める。幸い、Dockerコンテナ上で開発するためある程度の環境の際のリスクヘッジはできるはずなので、今回は妥協する。
  2. 開発が完了したアプリのv1をNginxコンテナと連携して、ECSを使いAWSへデプロイ。場合によっては、一度Nginxコンテナをdocker-composeで連携したローカル環境で稼働を確認してから行う。(要は「Nginxを挟まないdocker開発環境→Nginxを挟むDocker開発環境」のクッションを挟んでおく。)
  3. 新機能開発のためのCI/CDパイプラインを構築
  4. 新機能実装

以上のような手順で段階的にやっていこうと思う。

自分の悪い癖で、リスク回避を徹底するために最初から完璧を目指そうとするため、これを機に分割して順番に問題を解決するということも訓練できるようにしたい。

package-lock.jsonをgitに含めて良いか

今まで、学習のためでデプロイはしないからと特に気にしてなかったことを調べる機会があったため、メモついでに。

疑問

タイトル通りReactやVue.jsなど、Node.jsを触れていると大抵は見るpackage-lock.jsonをgitの管理下に置き、githubなどにpushして良いのかという点。

結論

先に結論から。含めた方がいいとのこと。それどころか、含めないとバージョン関連のエラーや不具合を引き起こす可能性があります。

package-lock.jsonの役割は実際にインストールしたパッケージのバージョンを厳密に固定し記録しておくこと。これがなければ、仮に別環境にパッケージを改めてインストールする場合、想定とは違うバージョンがインストールされる恐れがあります。これはチーム開発の場合や、本番環境へのインストール時に不具合を引き起こす元になりますよね。

なぜGitに含めて良いか迷ったのか

もともとRubyを学習している際にGemfile.lockという同一の役割を持ったファイルがあったので、似たような役割だと理解はしていましたが、中の記述に"integrity"という暗号化?された記述があったためGitHub等で公開してはいけないのでは?と怪しんだ次第。 また、拙い英語力で調べたnpmのドキュメントでは、これは「公開されない」というような記述があったため、さらに調査するに至りました。

この「公開されない」というのはどうやら、npmパッケージとして公開されないといった意味らしく、npm-shrinkwrap.jsonというものが、代わりにnpmパッケージの中に含めて公開できるという意味らしいです。

「Gitなどのリポジトリ」で「公開してはいけない」ではなく、「npmリポジトリ」に「公開されない」という意味だったんですね。

参考

ginpen.com

zenn.dev

docs.npmjs.com

qiita.com

engineering.mobalab.net

railsアプリ開発進捗その1

今回までにやっておくべき事

  • dockerによるrails開発環境の構築
  • スプリントごとに作業スケジュールを分け、Trreloで管理
  • 各画面のマークアップを全て終了

進捗

  • dockerによるrails開発環境の構築 完了
  • スプリントごとに作業スケジュールを分け、Trreloで管理 完了
  • 各画面のマークアップを全て終了 未完

反省点

  • dockerによるrails開発環境に苦戦した。dockerの大まかなイメージは掴めていたが、いざ実際のアプリ開発に応用しようとなると、実際に手を動かすまで時間がかかってしまった。

  • 初期段階での計画は各画面のマークアップを仮置きのルーティングで一斉にやってしまう予定だったが、冷静に考えてみると、後々実装を先延ばしにしたりする機能がでてくる可能性もあり、「細かく機能毎に段階を踏んで実装していく」という形の方が無駄が少なくすむと考えたため、昨日毎にマークアップをしていく方向に計画を修正した。

  • 就活をはじめてから、まとまった時間でrailsに触れる機会が激減した(Pythonなど寄り道もした)せいもあり、少し記憶が錆びついていた。また面接対策や面接そのもの、キャリア面談などで時間が削られた面もある。

  • 数日間モチベがガクッと下がったときがあった。もくもく会に行ったらいい刺激を受けて持ち直したため、積極的に勉強会には参加したい。

技術的な事

  • 技術的な備忘録はDropbox Paperなどにリスト形式で記述していくと、参考URLにリンクが貼れたりするので、ローカルのエディターでまとめるよりもわかりやすくまとめられる。

  • Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "exec: \"rails\": executable file not found in $PATH": unknownの解消は簡単。bundle execをつけて解決。

  • gemの追加をするにはGemfileに入れたいgemを記述し、docker-compose buildでイメージをビルドする必要がある。その後docker-compose upでコンテナを立ち上げると、Gemfile.lockにも入れたgemがきちんと記入される。bundle installではだめ。コンテナはイメージをもとにビルドしているから。

  • 通常のローカル開発で使っているrailsのコマンドを使用するにはdocker-compose run webを頭につける。

次回までにやる事

  • ユーザー登録、ログイン機能の実装。

何かしらオリジナリティのある要素入れたいな...

新しいRailsアプリケーション開発(備忘録)

どんなものを作るか

  • 自分の1日のスケジュールを公開でき、公開された他ユーザーのスケジュールを見ることで自分のスケジュールの見直しを図れるサービス。
  • 他ユーザーのスケジュールに「いいね」ができる。
  • スケジュールにコメントすることでアドバイスをしたり、されたりできる。

どうして作るか

  • きっかけはyoutubeの「a day in the life of a ~」系を見ていたら。
  • 自分の理想と現状のスケジュールの比較系アプリは多くあるけど、他人と比較する系は見当たらなかったから(題材的にn番煎じな気もする...)
  • 今までエネルギッシュな人を見て「どこにそんなにも時間があるんだ...」と思った経験があるから。
  • 最近Pythonと就活ばかりやっていてRailsのアプリが作りたくなったから。

どう作るか

手法:アジャイルな感じで。
インフラ:AWS
入れるべき使用技術:Docker, CIツール(Circle CIになると思う)

  1. 機能を洗い出す
  2. ワイヤーフレーム作成、画面設計
  3. DB設計、ここまで固まったらTrelloで機能ごとに期限切る。
  4. デプロイ
  5. フロント
  6. 機能毎にサーバーサイド実装

4,5,6あたりは調べたり進捗に合わせて変化するかもしれない。

気をつけること

  • JSを使う。(前作では使ってないため。いいね機能は非同期通信するためクリアできると思う)
  • それなりに見た目に拘る。(前作は余裕がなかった)
  • できるだけ1日の作業時間を8h以内にする。(効率的に考える習慣をつける)
  • Gitで管理するためブランチの切り方などは工夫して(特にプルリク関連)チーム開発のときを思い出してやる。

どこまで作ってあるか

f:id:kamiya-s-max:20200204170016p:plain
画面遷移図
f:id:kamiya-s-max:20200204165342p:plain
画面設計(の一部)
f:id:kamiya-s-max:20200204170253p:plain
エンティティとか
f:id:kamiya-s-max:20200204170342p:plain
ER図。とりあえずはこれで行こうと思う。

上記の通り、1,2,3は終わらせています。あとはTrelloでスプリント(一週間予定)ごとに予定切って、環境構築する感じですね。
Dockerを使う予定なので今までとデプロイと構築の仕方が変わる?ので、そのあたりの進捗が気になりますが。

キリのいいところでまた、記事にします。

TECH::EXPERT名古屋校について

お久しぶりです。カミヤです。3年ぶりの就活でバタバタしていてブログのことなど気にしていられん!となっていました。

就活の状況としては、最終面接までいった第一、第二志望の企業様にお見送りされてしまったという精神的大ダメージを受けた次第ですが、僕は元気です。

今回はタイトルにもある通り、僕が通っていたTECH::EXPERT名古屋校について良い所、気をつけた方がいいことをリハビリがてら書いていこうかと思います。

TECH::EXPERTとは

TECH::EXPERTはプログラミングスクールの一種で、エンジニアへの転職を前提に、必要なスキルを一通り身に着けるための学習をします。

内容については公式サイトを見た方がわかりやすいので割愛しますが、僕が通っていたエンジニア短期集中・転職コースは教室にほぼ毎日通い1日約10時間の勉強を10週間続けるというようなものでした。授業形式ではなく、カリキュラムを自分で進めていく形式です。また、修了後は求人の紹介もしてくれます。

最初は体力的にハードでしたが、慣れると大したことないということと、プログラミングそのものが楽しかったので僕はあまり苦にはなりませんでした。

良い所

  1. 通学型なのでダレにくい
  2. カリキュラム内容が充実
  3. その場でメンターに相談できる
  4. チーム開発の経験ができる

自分が感じた良い所は上記の4つでしたね。
1は文字通り、よく受験生が家じゃなく図書館とかで勉強するのと同じ理由ですね。

2はエンジニアに転職するうえで最低限求められる内容を学べるという意味です。ザックリ言うと、画面に何か表示するフロントエンド(HTML/CSSやJS)、画面には映らないけど色んな処理をしてるサーバーサイド(Ruby)、処理するデータの読み書き保存するDB(MySQL)、作ったアプリケーションを公開するデプロイ(AWS)とかを一通り学べます。特にAWSでデプロイする方法を学べるのは有用です。

3も文字通りその場にメンターが常駐しているので呼び出し画面で呼び出せば質問が可能です。かなりスケジュールがカツカツなので、5~10分詰まったら質問しましょう。

4が個人的に一番大きかったと思います。一人でアプリを作るのと複数人で作るのとは全然違うことを思い知りました。実務は大抵複数人で開発するはずなので緊張感の差こそあれど良い経験になると思います。僕のチームはキャラの濃いメンツだったのもあって笑いが絶えず楽しかったです。

気をつけた方がいいこと

最初は残念な所を書こうかと思ったのですが、ニュアンス的には気をつけるべきことの方が正しい気がしたので、そうします。

  • 名古屋の求人が少ない
    これは、紹介求人が、という面と、web系自社開発企業がという両方の側面があります。
    前者は、名古屋校が開校してまだ日が浅いためというのもあります。後者について、愛知はIT系企業は他の県に比べるとIT系企業が多いです(東京、大阪除く)。ただ、どのような企業が多いかと言うと、BtoB向けのSIerやSESがかなり多い印象です。愛知がモノヅクリが盛んなため必然的にそちらが多くなるようです。
    なので、BtoC向けのweb系自社開発企業が希望の場合は東京や大阪をおすすめされます。(といってもwantedlyなどを見てみると名古屋にもそこそこ数はあると個人的には思うけど)

  • スケジュールはかなりキツい
    かなりの詰め込み量です。さらに、同期との進捗率の順位が見れるようになっているので、競争心が刺激される反面、精神にも負荷がかかります。しかしながら量が多いのでそんなこと気にしてられなくなることもしばしば。
    しかし、実は、申し込んで入金が完了すれば正式開始の2週間前からカリキュラムと教室が開放されます。この事前学習は必ずやりましょう。具体的に言うと基礎カリキュラムを最低一周すること。もし二週できれば最強になれます。

  • 受講生が多い
    これは、入校した当初はそうでもなかったのですが、去年11月位から急激に受講生が増え、10:00までに行かないと席が確保できなかったり、ビデオチャットでのシステムがパンク?したり、質問したくてもメンターがなかなか来ないというような感じでした。さらには教室内が満杯のため、別のビルの一室を数週間に一度、臨時的に使うというようなこともありました。といっても、運営側もこれは把握しており、対策の真っ最中だと思うので、徐々に改善されるでしょう

  • 他の受講生との交流時間が毎日ある
    もしシャイな方なら死活問題かもしれない。朝礼と夕礼で予定や進捗について交流する時間が10分位あります。緊張したり、気が重くなる人もいるかと思いますが、慣れるので大丈夫です。僕もシャイな方でしたが慣れました。あと、よっぽど変な人はいませんし、先輩受講生と組むと割と気を使ってくれます。これは地味にいい経験です。

まとめ

まとめると個人的にはおすすめのスクールだと思います。料金は確かに高額ですが、内容を考えると妥当かと思います。

「手取り足取り教えてくれる授業形式ではないのに高すぎないか?」と思う方もいるかもしれないですが、エンジニアと言う職種自体が手取り足取り教えてもらえるというタイプの仕事でないので、この料金設定の本質は「転職に最低限必要な知識」を「強制と自主的の中間の不可で」行えて、且つ、「チーム開発」や「メンターへの正しい質問の仕方」ということを学ぶための環境を提供している部分にあると思います。

おわりに

偉そうなこと&とんでもない長文を書きましたが、以上がTECH::EXPERT名古屋校に通ってみて感じたことです。
実のところ修了してから就活に入り、最終面接が終わると緊張感が多少緩みモチベが低下していた気がしています。

第一、第二志望に落ちてしまったのは残念ですが、そのおかげで気合いは入りましたし、スクールのことを思い出してみると、あの頃の希望に満ちた気持ちが少し蘇ってきたので、これは必然だったのかもしれません(もちろん面接は全力でやったし、掴みも悪くありませんでした。しかし適性検査がね…)。

また、心機一転やって参ります。ちょうど作りたいアプリのネタもいくつか思いついたし。

ブログ開設

自己紹介

はじめまして、カミヤと申します。

 

前職を今年7月に退職後、TECH::EXPERTというプログラミングスクールに通い、プログラミングの学習を修了し現在は愛知県でエンジニア目指して就職活動をはじめたところです。

 

もともと自分は発信が決して得意な方ではないんですが、あまり表に出す機会がない自分の考えの発信や、単純に自分のための技術的な備忘録として執筆していこうかなと思います。

前職

まずはじめに前職のことを書きます。前職はとある市のとある公益法人の職員をやっていました。転職サイトとかで出てくる半官半民だとか団体職員、準公務員と言われるところです。

 

僕のいた職場は地域密着型でいわゆるローカルな感じでした。市民と関わりがかなりある所だったので地域貢献感はかなりあって、「地元を盛り上げたい!」っていう人には天職だと思います。

 

なぜ、退職してエンジニアになろうと思ったの?ってところまで書こうとするとかなり長くなるのでまた別記事で書こうかなと思っています。

 

 

今後のこと

今現在の就活状況というと、5社書類を出して、

  • 1社書類選考中
  • 1社最終面接(場合によっては回数増えるかも)
  • 2社一次面接(1社は場合によっては最終面接になるかも)

が通過状況ですね。転職活動的にいい時期は11月頃らしいのですが(来年採用の準備で求人を出しているのがこの時期が多いそうです。)、スクールのカリキュラムとポートフォリオの作成の関係で12月初旬からのスタートとなりました。

 

今後は

  1. 就職活動
  2. ポートフォリオの改修
  3. 以前からやりたかったPythonの学習(今はPyQで基礎やってますが、そろそろ本題のTelloのプログラミングをやっていこうと思います)

の三つを軸に活動していく予定です。

 

ブログの書き方ってこんな感じでいいのだろうか…