アプリ開発者へ転職して５ヶ月後の振り返り

アプリ開発者として転職して５ヶ月経ったので、振り返りを書こうと思います。

目次

  • 前書き
  • ３月にやったこと
  • 終わりに

前書き

ゆうたです。

４月になりました。

前よりだいぶ暖かくなって桜が咲いてやっぱり４月はいい季節ですね。（花粉を除いて）

神奈川の千本桜を散歩程度に見に行ったのですが、

外でブルーシートを広げて、持ってきたランチを食べながら家族連れやカップルで花見をしている方が大勢いました。

花見いいですよね。

非日常って感じで個人的にかなり好きです。

ってな感じで私の話ですが、アプリ開発者に転職してから早いもので５ヶ月経ちました。

バックエンドの軽微な改修ができたのと、Zodのバリデーションチェックによるバグを解消できたのは良かったと感じてますが、まだまだ一人前には届いてないというところです。

最近振り返りを書けてなかったので、キャッチアップしたことや実務でアウトプットしたことを書こうと思います。

３月にやったこと

  • UIコンポーネントの修正
  • テストNGのバグ改修
  • 別導線からの登録処理の実装
  • マスタのcsvファイル出力機能の実装

主にフロントエンドのバグ修正を行いました。

フロントエンドの修正にバックエンドの修正が絡む場合は、

バックエンドの修正も行いました。

重要なところだけ書いていきます。

テストNGのバグ改修

これ何やったかと言うと主にUIの修正だったのですが、

一部バックエンドの修正が必要な部分があって、

具体的に言うと指定した条件による絞り込み検索の修正なんですが、

この条件の時は過去日付を表示しない。

この条件の時は未来日付を表示しない。みたいなことを実装する必要があったんですね。

で、私が携わってるプロダクトはバックエンドはLaravelを使ってるので、

Eloquentの修正が必要だったんですけど、やってみて本当に良かったと感じてます。

EloquentはそもそもSQLをPHPで書いたものなんですが、最初見た時？？って感じだったんですよね。

本当に「なんだこりは？」って感じ。

実務に入る前にわずかな無職期間でキューピッチでPHPとLaravelのキャッチアップをしたのですが、実務に入ってからReactとTypescriptを使ったコンポーネント登録によるUI刷新プロジェクトで、Laravel使ってなかったんでほとんど忘れてしまったんですよね。

ただバックエンドもできないと話にならないので、業務の合間に少しづつLaravelのキャッチアップをしていって「あー、こんなことやったな。」とか「あー、あれそういうことだったのか」とか思い出したりしました。

で実務でLaravelの実装をついにやる日が来てわからないところは生成AIに頼りつつ、SQLをなんとかPHPで書いて絞り込み条件を要件に合うように修正した感じですね。

public function __invoke(Builder $query, $value, string $property): Builder
    {
        if ($value === OrderStatus::ON_GOING->value) {
            $today = now()->startOfDay(); // now()で今日日付を取得しstartOfDay()で開始日付を取得
            $query->where('status', 'OnGoing') // statusがOnGoingのものを条件指定
                ->where(function ($query) use ($today) { // サブクエリを設定
                    $query->where('delivery_date', '>=', $today) // delivery_dateが今日日付以降のデータ
                        ->orWhere('delivery_date', null); // もしくは今日日付がnullのデータを取得
                });
            return $query;
        }

実装の一部とはいえ、改修箇所は本当にわずかですね。

まぁ最初はこんなもんですよね。

バックエンドに１歩踏み出せたということで良しとしておきます。

別導線からの登録処理の実装

これが苦戦しまして。。

結論として実装までやり切れませんでした。

理由としてはReactのライフサイクルが原因で削除したデータが復活してしまう事象が発生しまして、

原因箇所を２箇所ほど切り分けたものの、別のタスクを優先して欲しいとのことで実装まで持ってくことができませんでした。

Reactのライフサイクルは自分の課題だなと感じました。

マスタのcsvファイル出力機能の実装

この実装が一番チームに貢献できたタスクだと感じてます。

// 出力データの型定義
export type ExportField = {
  label: string;
  key: string;
  format?: (value: any) => string; // 出力する時にフォーマットを変える為のプロパティ
};

// カスタムフックを定義
export const useDataExportCsv = <T extends Record<string, any>>(
  filename: string,
  fields: ExportField[]
) => {
  const [isLoading, setIsLoading] = useState(false);
  const execute = (data: T[]) => {
    if (isLoading) return; // ローディング中はボタン押下できないようにする
    try {
      setIsLoading(true);
      if (!data) {
        message.error("出力可能なデータが存在しません");
        return;
      }
      const csvData = data.map((item) => {
        const row: Record<string, string> = {}; // 空のオブジェクトを定義
        fields.forEach((field) => {
          const value = item[field.key]; // keyをvalueに格納
          row[field.label] = field.format ? field.format(value) : value ?? "";
        }); // formatがあればformatに則ったをlabelに格納、特に指定がなければ値をそのまま格納し、nullなら空文字を格納
        return row;
      });
      // csvファイルを成形
      const csv = convertToCSV(csvData);
      downloadCSV(csv, filename); // 整形したcsvファイルを設定したファイル名で出力
    } catch (e) {
      message.error("取引先のcsv出力に失敗しました");
    }
    setIsLoading(false);
  };
  return { execute, isLoading };
};

使う時はこんな感じ

<CustomButton
  variant="white"
  size="md"
  onClick={() => 
    tableProps?.dataSource && execute([...tableProps.dataSource])} // 画面にデータが存在すればevecute関数を実行してデータを展開し引数として渡す
    loading={isLoading}
>
csv出力
</CustomButton>

Reactは前に比べたら少しはマシになった気がします。
UI刷新プロジェクトでコンポーネントをReactとTypescriptでガシガシ作ったのが今に活きてると感じてます。
コードレビューに粘り強く伴走してくれた上長に感謝です。

終わりに

書くことそんなになかったですが、自分の棚卸しは少しはできたと感じてます。

まずは継続するところからですね。

あとはバグ改修とかじゃなくて、TypescriptのZodライブラリとかバックエンドを自力で機能実装できるところまで持ってかないとマズイですね。

あとはReactのライフサイクルの理解を深めることが私の課題かと。

できないといけないことが山積みで、キャッチアップに気を抜けない日々はまだまだ続きますが、なんとか食い下がって実務でアウトプットし、チームに貢献していきます。

今回は以上です！

アプリ開発者に転職して１ヶ月の振り返り

アプリ開発者として転職して１ヶ月経ったので、振り返りを書こうと思います。

目次

  • 前書き
  • １１月にやったこと
  • 良かったところ
  • 悪かったところ
  • 学んだこと
  • 今後について

前書き

ゆうたです。

29歳からプログラミングの勉強を始めて31歳で転職できました。

 

今年もあと１ヶ月で終わりですね。

転職して早々に今年が終わるので、新しいことに挑戦するには良かったタイミングだったかもしれませんね。（どういうこと？）

 

前職ではサーバの運用保守なることをしてたので、アプリ開発者と密接にコミュニケーションをとりながら、月に一回行う月次のアプリケーションリリース（要は新たな機能の追加や改修etc）の手順書作成とかなんやらやってましたが、今年の２月に退職してから有給と失業保険を受給しながらプログラミングの勉強をしていたので、働くのはなんと８ヶ月ぶりと。

ようニート期間をここまで引っ張ったもんだなと、このブログを書きながら気づいてある意味すごいことをしたなと感じました。（社会復帰できて良かったね！！）

 

とまあそんな感じでなんとか転職を果たせたものの、開発の仕事はというと技術のキャッチアップが中々大変でした。

１１月にやったこと

振られたタスクの要件を確認して、要件で分からない部分があれば業務担当者にどういうふうに機能を実装するか会話したり、技術でわからないことがあれば上長に確認して開発を進めたりと、そんな感じで開発は進めてます。

 

１１月にやったことをざっと下に列挙していきます。

 

1. Lalavelで作られた既存のプログラムを流用して、画面のデータをcsvファイルとして出力する。

2. 画面に表示されるモーダルの修正

3. 帳票として出力されるpdfの修正

 

ざっと書いてみましたがまだまだ数が少ないですね。

土日もコードを書いてコードの理解度を上げていこうと思います。

具体的にはTypescriptの型定義に慣れるのと、Typescriptを用いたReactの書き方に慣れるところかな。と感じてます。

良かったところ

  • Frontの既存機能の改修なら２日でレビューまで持ってけた
  • 休みの日も商用のコードに触れることができた

既存のコードを流用して機能を改修ものについては２日くらいで実装できたのは悪くなかったと感じてます。

また、休みの日も商用のコードに触れるのは良いことだという風に感じました。

今の職場にアサインされて２週間くらいは自分の中で理解が曖昧だと感じたものの復習と学んだことを使って簡単な成果物を作ってみるということをやってみたのですが、

それだと商用で使われる技術に直接関わるもの以外にも時間を割くことになるので効率的じゃないという風に感じました。

なので、自分で理解が曖昧だと感じる技術をUdemyで補うのも大切なんですが、商用のコードに触れて少しでも早く現場に貢献できた方がいいと考えるようになりました。

 

悪かったところ

  • 生成AIに頼りすぎ

生成AIがなかったら一部のコードを書くのに１週間以上かかってたかもしれないと感じます。原因としてはpropsの連携やTypescriptの型定義などコードの全体像が掴めてないと感じたので、１行ずつそのコードがなぜそこにあるのか。意味を正確に理解することが必要だなと感じました。

 

学んだこと

Backend

  • var_dump
  • $selfは自クラス、$thisは自身のオブジェクトを指す

Frontend

  • 型アサーション
  • typescript（オプショナル、Omit）
  • アトミックデザイン
  • AntDesign

パッと出てきたのは以上ですね。

思ったより少ないと感じたので、次回以降は具体性を上げるようにします。

今後について

引き続き商用のコードに触れる時間を増やすのはやっていきたいと思います。

あとコードを正確に理解することも心がけないといけませんね。

抽象的な理解のまま歩んできたツケが今にきてるので、ここから改善していくようにします。

そんな感じですね。

 

以上です！

JavaScript Primer - 迷わないための入門書 #jsprimerを読了した感想

JavaScript Primer - 迷わないための入門書 #jsprimer
を読み終えたので、学習した内容をこちらにまとめます。

目次

  • 学習した目的
  • 良かったところ
  • 悪かったところ(もしあれば)
  • 学んだこと
  • 難しかったこと

学習した目的

フロントエンドの技術の学習をするにあたって、基礎になる言語であるJavaScriptを学ぶ為にこちらのドキュメントを学びました。

良かったところ

  • 無駄なく網羅的にJavaScriptについて学べる。
  • 簡単なアプリを作りながら学べる。
  • チートシートは有効に使えそう。

リファレンスとは違い入門書として書かれており、量は多いもののJavaScriptを実務レベルで使う上で必要になる知識が無駄なく、簡潔にまとめられてる印象を受けました。

悪かったところ

  • 1回で理解するのが困難を極める。

プログラミングの習得はやはり簡単ではなく、そもそもの量がどうしても多いと感じました。

まとめ

thisという特殊なキーワードや非同期処理、HTMLと連携した上でのコードの書き方など、pythonとはまた違った文化を理解するのにまだ時間がかかりそうだと感じると同時に、書き方に困ったらこのドキュメントを参考にしながら開発を進めていこいうと思いました。

 

以上です。

djangoチュートリアルの感想

djangoのチュートリアルを終えたので、学習した内容をこちらにまとめます。

目次

  • 学習した目的
  • 良かったところ
  • 悪かったところ(もしあれば)
  • 学んだこと
  • 難しかったこと

学習した目的

Webアプリケーションを作成するためにフレームワーク使用するのでdjangoを学習しました。

良かったところ

  • webアプリケーションを作りながら学習を進めることができる
  • テスト駆動開発を学べる

投票システムを作りながら学習を進める形なので手を動かしながら学習できるのは良いところだと思いました。

また、テスト駆動開発についても説明しており、コードを書く前にテストコードを書いてからそれをクリアするためのコードを書くという考えたは勉強になりました。

悪かったところ

  • システムを実装するのが難しい

既存のコードを残しつつ修正する部分があったりして、修正を少しでも間違えればシステムがクラッシュすることが頻繁にあり、動くものを実装するのがとても難しかったです。

まとめ

事前にdjangoの勉強をしてから臨んだのですが、内容がとても難しく実際にシステムを作りながら読み返していく形で活用していく必要があると思いました。

 

以上です。

REST APIについて

REST APIについて学んだので、学習した内容をこちらにまとめます。

目次

  • 学習した目的
  • 学んだこと

学習した目的

RESTfulなURL設計ができるようになるためにRESTについて学びました。

学んだこと

RESTとは

RESTとは一言で言えば、「分散型システムを構築するときに使う設計ルール」となります。

６つの設計原則から成り立つものになるのですが、それぞれ説明すると説明が長くなりそうなので、RESTについてはここまでとさせて頂いて後続のREST APIの説明に移っていきたいと思います。

 

REST APIについて

REST APIの設計レベルは大きく分けて4段階になるのですが、ここではよく見かけるLEVEL2にスコープを当ててまとめていきたいと思います。

 

REST APIの設計レベル２はリソースごとにHTTPメソッドを活用していく設計となります。

リソースというとサーバリソースかと思われますが、そういった意味のリソースではなくここではあくまでアクセス可能なオブジェクトを指します。

Web API 設計のベスト プラクティス - Azure Architecture Center | Microsoft Learnより以下引用

REST API は "リソース" を中心に設計します。リソースは、クライアントがアクセスできるあらゆる種類のオブジェクト、データ、またはサービスです。

 

そしてHTTPメソッドは以下になります。

  • POST　リソースの作成（リソース名が未定）

  • PUT　リソースの更新、新規登録（リソース名が決まってる）

  • GET　リソースの取得

  • DELETE　リソースの削除

まとめ

これまでサーバの運用業務に従事していたときにAPIへどのようなリクエストがいくのか見ていたことがあったのですが、それが上記のような設計方針に則って作られていたとは知りませんでした。

言われてみれば各APIごとにリクエストパラメータのリソース部分が違ってたので、RESTによる設計原則に則って様々なシステムが作られていたんだなと改めて気付かされました。

 

以上です。

達人に学ぶDB設計徹底指南書 感想

DB設計について学んだので、学習した内容をこちらにまとめます。

目次

  • 読んだ目的
  • 良かったところ
  • 悪かったところ(もしあれば)
  • 学んだこと
  • 難しかったこと

読んだ目的

掲題の参考図書を読んだ主な目的は以下になります。

達人に学ぶDB設計 徹底指南書

  • DB設計の手法を学習する

DBについての知識の習得のために掲題の参考図書を読んだ次第となります。

よかったところ

  • DBのパフォーマンスも考慮した設計が学べる

悪かったところ(もしあれば)

  • 実践で使うまで通読が必要だなと感じました。

内容がよくないという訳ではないのですが、理解するのがとても難しく実践で使うには本書を振り返りつつ経験を積む必要があると感じました

まとめ

DB設計の本を読んだのが初めてだったのですが、キャパシティとパフォーマンスに折り合いがつくような平衡点を探ってDBを設計したり、正規化などカリキュラムを進めつつ復習が必要だなと感じました。

今後はDBを設計する際のバイブルとして活用していこうと思います。

 

以上です。

スッキリわかるSQL入門 感想

SQLについて学んだので、学習した内容をこちらにまとめます。

目次

  • 読んだ目的
  • 良かったところ
  • 悪かったところ(もしあれば)
  • 学んだこと
  • 難しかったこと

読んだ目的

掲題の参考図書を読んだ主な目的は以下になります。

スッキリわかるSQL入門 第3版

  • SQLの基本的な操作を習得する
  • 基本的なDB設計の手法を把握する

補足ですが、現在Happiness Chainというプログラミングスクールで学習をしておりまして、DBについての知識の習得のために掲題の参考図書を読んだ次第となります。

よかったところ

  • dokoQLが秀逸
  • DBの基本設計についても少しではありますが学ぶことができる。

悪かったところ(もしあれば)

  • 付録のエラー解決虎の巻は蛇足な気がしました。

 

まとめ

基本的なDMLやサブクエリ、結合と基本的な操作が分かりやく解説されていて、入門書としては最適でした。

 

さらにdokoQLというサービスを使えば、環境構築不要、かつ無料でDBを操作することができるのは素晴らしいサービスだと思いました。

ただ、あるに越したことはないのですが付録のエラー解決虎の巻はネットで検索すれば解決できそうなものばかりで、本書に記載するのは少し蛇足かなと感じました。

 

とはいえ本書でSQLの基本的な操作は抑えることができたので手に取ってよかったというのが総評です。

 

以上です。