ラムダラボ体験

代入-ペットグルーミングスケジューリングアプリ
ラムダラボユニットの間、8週間私はラムダ研究所ペットエクスプレス組織で働いた.この組織の目標はペットの飼い主がペットのグルーミングサービスを見つけ、スケジュールすることをより簡単にすることです.我々は最後のチームが去ったところからこのプロジェクトを取り上げた.彼らは重いバックエンドと光フロントエンドを構築した.彼らは3週間目にバックエンド開発者として私を設立しました.それは私がフロントエンドで働くことができないと心配しました、そして、残念なことに、それは我々が2人のバックエンド開発者と6台のフロントエンド開発者に分けられるようでした.バックエンドの私達の最初のタスクは、ユーザーが作成/再スケジュール/キャンセル/予定を得ることができるようにエンドポイントを作成することになっていたとグルマーは/再スケジュール/キャンセル/予定を承認することもできます.

予約スケジューリングに挑戦
任命エンドポイントを構築すると、我々は任命の日付の時刻を扱うなどのいくつかの技術的な課題に走った.最初に、日付と時刻はデータベースの2つの列でした、そして、それが働いた間、フロントエンドがユーザーのタイムゾーンへの約束の日付と時刻を変えるのを取り扱う必要があると理解しました.タイムゾーンに対処することは頭痛と簡単に見落とされることができます.この問題に対する解決策は、予定表のテーブルを1つの列にすることで、TextmentmentCount DateCount時間を処理することでした.私たちは、このコラムに、1970年1月1日からのミリ秒の数である約束の日付時刻のUnixタイムスタンプを格納します.これは、UNIX時間を日付オブジェクトに変換することによって、ユーザーの読みやすい日付時刻にUNIX時刻を変換することができます.
例:

```
const unixTime = 1612397014
const date = new Date(unixTime)
// date returns the date time in the current users Time zone: ‘Date Mon Jan 19 1970 09:53:17 GMT-0600 (Mexican Pacific Standard Time)’```

これに加えて、我々はGroomerがすでに要求された時間の間予定される予定を持っているとき、ユーザーのものがグロマーで予定を要求していなかったことを確認する必要がありました.これは、グルマーがダブル予約を取得し、ユーザーの要求を再スケジュールを要求することを停止します.我々は、持続時間と一緒にグルーマーの予定のすべての時間を取得し、予定の予定の期間中に要求された時間が表示されるかどうかを確認するポスト/予定ルート上で実行するValidateAppOntmentTimeと呼ばれるミドルウェアを作成することによってこれを行うことができた.

const validateAppointmentTime = async (req, res, next) => {
  try {
    const groomerApps = await appointmentsModel.getAll(req.body.groomer_id);
    groomerApps.forEach((appointment) => {
      const durationSeconds = appointment.duration * 60;
      const appEndTime = appointment.appointment_date_time + durationSeconds;
      if (
        req.body.appointment_date_time >= appointment.appointment_date_time &&
        req.body.appointment_date_time <= appEndTime
      )
        res.status(409).json({
          message: `The groomer already has an appointment schedule at the requested time`,
        });
    });
    next();
  } catch (e) {
    console.error(e.stack);
    res.status(500).json({ error: 'Error validating appointment time' });
  }
};

我々が残したもの
結局、私たちは仕事に予定スケジューリング機能を出荷して、APIのためにドキュメンテーションを書くことによってSwagger/OpenAPI標準経験で経験を得ることさえできました.私は、ドキュメントを作成するためにswaggerを使用せずにAPIを書くことを予見しません.
バックエンドに関するアプリケーションの将来のために、フロントエンドの将来の機能として、特にフロントエンドの将来の機能として、位置とサービスのシンプルさに影響を与える4つのテーブルがあるとき、位置とサービスがどのように扱われるかについて、データベーススキーマをリファクタリングする必要があります.フロントエンドの将来の機能は、フロントエンドのMapboxのようなマップされた地図の内側の地図点に行くことによって位置でスケジューリングサービスになるでしょう.
私は自分自身についてのこのアプリの作業から学んだこととチームとの作業については、特に私は自分の快適なゾーンのコミュニケーションについては、特に私は恥ずかしがり屋ではなく、任意のボートをロックしようとする自分をプッシュする必要があります.これは私たちのフロントエンドは非常に遅くまでバックエンドでの作業をテストしていないとして、このアプリケーションでの作業に欠陥.将来的にチームと一緒に仕事をしているので、私たちは深夜まで数秒しかないのに問題を見つけるのをやめないように機能的に働くことについてもっとボーカルになります.
ラボで働いていた経験は、コミュニケーションとチームを新しい機能の出荷としてプライオリティーの大きなものとして置くことを考えることで、私のプロの開発キャリアを助けてくれます.