はじめに
この数ヶ月間、どこにいたのですか？
なぜブログを放棄したのですか？
何を学びましたか？
これらは、ブログの投稿を見に入った人が考える普通の質問です。いいえ、私は学びたいという欲求を放棄していません。むしろ、9月下旬から今まで、ブートキャンプでプロジェクトのためにチームとして学び、働いてきました。
多くの推薦を受けた後、私は自分の心が覚えられる限り多くのテクノロジーを学ぶ目的で、この（集中的な）3ヶ月のコースに挑戦しました。
リポジトリと基礎の作成
私たちのプロジェクトとは何ですか？
従業員の勤怠記録を保存し、休暇を表示し、毎日および毎月の時間の要約を可能にするアプリケーション。一方、企業は労働者のすべてのデータを見ることができ、それらを管理し、祝日を設定できます…
これらすべてを知った上で、2つのリポジトリで開発を開始しました：フロントエンド用とバックエンド用です。このようにして、企業にいる場合、お互いの仕事を踏む必要なく、作業を2つのチームに分割できます。
「マルチリポ構造を知る前は、ほとんどすべての人が異なるフォルダーで前面と背面を分離していましたが、同じリポジトリにありました。これにより、古典的な構造を超えて見ることができ、より高いレベルですべてがどのように機能するかを理解するために必要な複雑さを与えることができました。私が見る唯一の欠点は、最初にすべてを立ち上げるのに少し時間がかかることですが、長期的には利益があります。時間とチーム間の競合を節約できるからです。」
異なるリポジトリを作成したら、私にとって未知のテクノロジーであるGitHub Actionsを使い始める必要がありました。GitHub Actionsとは何ですか？JenkinsやTravisのような他の有名なものと同じように、CI/CDのためのツールです。おそらくプロジェクトで大きな重要性を与えられることはありませんが、開発していた各機能をデプロイする際に非常に役立ったと言わなければなりません。
私がいつも考えることの1つは：**このタスクを何度も行うつもりですか？**答えがノーの場合、手動で行うことがおそらく最も賢明です。時間を少し費やして完了します。そうでない場合は、将来の反復的なタスクを節約するために何かを自動化することに時間を費やす方が良く、そこでActionsが登場します。
アイデアは、作成した機能がある場合、テストとリンターが問題なく通過することを確認し（万が一見逃したものがある場合に備えて）、その後、最終的なWebサイトがあるサーバーにその最終コードをデプロイすることでした。最初の部分はCI（継続的インテグレーション）で、2番目はCD（継続的デプロイメント）です。
後でActions構造の改善が提示されました。サーバーであまり多くの変更を行う必要がないように、dockerhubのリポジトリにコードをアップロードし、リポジトリから新しい更新を直接ダウンロードします。
完璧です。構造全体が整理され、デプロイする準備ができました…どこに？一般的に、ドメインを購入する同じWebサイトでWebホスティングを提供していますが、このコースでは、教師が素晴らしい計画を持っていました：GitHubの学生バックパックをリクエストします。これにはDigital Oceanで使うお金が含まれており、Webサイトをホストし、好みに合わせて設定できるdropletsを作成できます。素晴らしく聞こえます、完璧な計画…漏れを見つけるまで。バックパックをすべて拒否されました（╯‵□′)╯︵┻━┻
冗談はさておき、グループで作業していたので、dropletの価格を均等に分割でき、超安くなったので、あまり重要ではありませんでした（1人あたり約4〜5ユーロ）。
dropletには何がありますか？
DockerHubに保存されているイメージを実行できるようにDockerをインストールし、ユーザーが見るWebサイトの最終ファイルを提供するためにNginxをインストールしました。Dockerで3つのコンテナをセットアップしました：front、back、database。
テクノロジーの選択と欠点
コース中の私たちの目標の1つは、知らないことから学び、コンフォートゾーンから抜け出すために未知のテクノロジーに身を委ねることでした。私たちのイデオロギーは、現れる機会を利用することであり、それが私たちがしたことです。
フロントエンド
フレームワークとして、ReactとVueのどちらかを選択できました。このブログの読者であれば、私がReactで作業したことをすでに観察しているかもしれませんし、他のチームメイトも同様です。したがって、ここではほとんど疑いがなく、Vueを使用することにしました（興味深い事実として、コース中にVue3が出てきて、魅力的なオプションのように思えましたが、ドキュメントの量とVue3が非常に新しく、まだ小さなバグがある可能性があるため、vue2で行うことを勧められました）
私たちが下さなければならなかったもう1つの決定は、純粋なCSS、プリプロセッサ、tailwind、bootstrapなどを使用するかどうかでした。個人的にTailwindCSSを紹介されたとき、このプロジェクトでは使用しないことに非常に賛成でした。なぜなら、私の意見では、クラスを入れすぎることでコンポーネントコードを少し汚し、長期的には読むのが複雑になるからです。それでも、グループの決定として最終的に使用することになり、bootstrapと同じように使いやすいことを発見しました。Tailwindを使用することでCSSを学ぶ必要がなくなるわけではなく、むしろ逆です。Tailwindを最大限に活用するには、基礎をよく知っている必要があります。
Vueには利点があり、同じSFC（Single File Component）ファイルに3つのセクションがあります：
- Template：すべてのHTMLを配置する
- Script：コンポーネントロジックが入る場所
- Style：コンポーネントに適用されるスタイル
この分離を考慮すると、TailwindCSSではTemplateとStyleを混在させることを余儀なくされます。これは私を完全には納得させません。試し続ける必要があります
バックエンド
バックエンド用の他の2つの選択肢はNodeJSとGoでした。ここでは、どの言語を使用するかについてもう少し議論がありました。NodeJSははるかに手頃で簡単に使用および理解できるように思えました。しかし、Goは完全に未知でした。また、現在定期的にこの言語で作業している教師の助けがあったため、質問で彼を絞り出すことが最初からの私たちの意図でした
API開発の中で、ルーティングにGorilla MuxまたはGin Gonicのどちらを使用するかを選択できました。
Gin Gonicの方が美しいと思い、いくつかの理由で注目を集めました：
- スピードを自慢しており、試してみることを奨励します
- 簡単な実装と使用
- 良いロゴ、オリジナルで面白い = +10ポイント
遭遇した問題
1つの投稿ですべてを数えるには多すぎますが、要約として最も重要なものを含めます：
データベースの自動インポートの問題
GORM（使用したORM）はいくつかの選択肢を提供し、自動インポートによってデータベースのテーブルを直接作成できますが、クエリを作成する際に問題が発生しました。そのため、独自のテーブルモデルを作成し、ファイルごとに分離し、リクエストとレスポンスのjsonとバインドする必要がある各フィールドを設定することにしました。
ORMを使用することは、使用方法を学ぶために時間の投資が必要なタスクです。プロジェクトが長期間続く場合は、間違いなく非常に役立ちます。ただし、短い小さなプロジェクトの場合、あまり価値がないことを学びました。
- そうでなければ空のフィールドが表示されるため、クエリのための結合
もう1つの問題は、クエリの結果をJSONとしてフロントに返したかったのですが、テーブルを混在させた基本的なクエリが残りのフィールドをすべて空で返した（レスポンスで使用されなかったもの）ことでした。これは、結合を適切に使用していなかったためです。
- JSでの日付
日付を扱うことは、複数の頭痛を引き起こす可能性があります。時間不足のため、フロントに責任を委任し、日付を正しく表示するようにしました。バックエンドからは、エントリと終了時間がタイムスタンプ形式で記録され、フロントからはDayJSというライブラリを使用して、その情報を理解可能な方法で表示します。
なぜMomentJSではなくDayJSなのか？
プロジェクトを発表したときに同じ質問をされました。答えは簡単です：MomentJSはそのドキュメントで新しいプロジェクトにライブラリを使用することを推奨していません。特定の制限があり、インターネット上で現在動作している何千ものプロジェクトを壊してしまうため、明らかに変更できないためです。しかし、代替案を提供しています。その中にはDayJSがあり、実装が非常に簡単で、多くの興味深いオプションがあります。
コード構造
バックエンド構造
バックエンドでは、多くの議論の後、すべてをJavaバックエンドのように構造化することになりました。main.goファイルでは、ポート8080へのセットアップでAPIを提供します。そこから、routesフォルダーからルートが取得され、controllersフォルダーにリダイレクトされます。次に、domainフォルダーがデータベースへのクエリを行うinfrastructureへの呼び出しを確立する責任があります。modelsフォルダーは、アプリのさまざまなエンティティの構造を確立します。
フロントは少し広範囲ですが、要約として、テストとストーリーを含むフォルダーに各コンポーネントを編成しました。componentsとutils（APIへの呼び出しを行う責任がある）の間に中間層を確立し、domainと呼びました。この中で、各呼び出しをセグメント化し、対処しやすく、分離することでより読みやすくするために、さまざまなサービスを作成しました。
結論
ここまで来て、最終製品を見たい場合は、ここから見ることができます。データを使用するつもりはない基本的なアプリであるため、発明されたメールアカウントとパスワードを使用することをお勧めします。したがって、個人情報の痕跡を残さないために、動物アカウントを使用してください🙊🙉🙈
このようなプロジェクトの実現中に、千の問題と千の挫折が発生します。これは私たちに頭を集中させ、「Webサイトにこれを追加するのがどれだけクールか」や「これを試してみたらどうか？」という典型的なフレーズの中でとりとめなく話すのではなく、MVPに準拠することを教えてくれます。プロジェクトに関する私の意見は、CI/CDに多くの時間を費やしたということと、サーバー構成です。その後、バックエンドに入り、希望どおりに残すには少し時間が足りませんでした。最後に、フロントはレースでした。すべてを素敵に構造化できるかどうかを確認するためです。時間をパーセンテージで分配する必要がある場合、次のように言います：
- 40％サーバー、環境構成、データベース、droplet、CI/CD…
- 40％バックエンド
- 20％フロントエンド
しかし、最終結果には満足しています。実装するものがいくつか欠けており、フロントエンドをもっと深く掘り下げたかったです。
コメント