20210221のReactに関する記事は14件です。

投稿日：2021-02-21T22:12:46+09:00

JavaScriptでcsvダウンロードを実装する方法

はじめに

フロント(React)でcsvダウンロードを実装する機会があったため、備忘録です。
どうぞご活用ください。

実装

  const handleDLcsv = async () => {
    //アイテムの定義
    const download_items = [
            {'id': 1, 'name': 'apple', 'price': 100},
            {'id': 2, 'name': 'orange', 'price': 120},
            {'id': 3, 'name': 'melon', 'price': 800}
    ];
    //csvヘッダー
    const array_data = [['id', 'name', 'price']];

    //文字コード
    const bom = new Uint8Array([0xEF, 0xBB, 0xBF]);

    //csv用データ作成
    download_items.map((item) => {
      const item_data = [item.id, item.name, item.price];
      array_data.push(item_data);
    })
    let csv_data = array_data.map(function(l){return l.join(',')}).join('\r\n');

    //BLOB生成してダウンロード実行
    const blob = new Blob([bom, csv_data], { type: 'text/csv' });
    const url = URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = 'csv_file.csv';
    const clickHandler = () => {
      setTimeout(() => {
        URL.revokeObjectURL(url);
        a.removeEventListener('click', clickHandler);
      }, 150);
    };
    a.addEventListener('click', clickHandler, false);
    a.click();
  }

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T21:11:53+09:00

ISR(Incremental Static Regeneration)とは？

ISR(Incremental Static Regeneration)とは？

Next.js のビルドにはいくつかパターンがあります。その中でNext.js 9.4 からIncremental Static Regeneration という機能が導入されました。

直訳すると、(段階的な静的サイト生成)となります。
簡単に説明すると、リクエストに対して静的にビルドされたページを返す。かつ、有効期限を超えたら非同期で静的ページの再生成をSSRで行うことです。

メリットって？

事前にすべてのページ生成はせず、1度リクエストされた際のレスポンス内容が生成される。

アクセス時に初めて生成されるので初回ビルドが高速になる。

一定期間ごとにSSRを行うので、描画が高速になる。

CDNのキャッシュを有効活用しつつ、静的ページの更新を自動的に行え、一定時間後再度リクエストがあった場合、次回以降の内容をビルドするので内容が更新される。

VercelにDeployしてみる

ISRのpagesコンポーネントを作成

getStaticProps で revalidate を設定すると ISR になります。

revalidate の値は、前回から何秒以内のアクセスを無視するかを指定します。
pages/index.tsx
export default function Index({current}) {
  return (
    <div>
        現在時刻は{current}です。
    </div>
  );
}

export async function getStaticProps() {
    const date = new Date();
    const current = date.toLocaleString()
  return {
    props: {
      current,
    },
    revalidate: 10,
  };
}
VercelにDeployしてみる

上記のコードをVercelにdeployして挙動を確認してみました。
コード的には、10秒間はキャッシュされたデータが返却され、10秒後に再描写され内容が更新されていることが確認できます。

参考

Zenn 個人開発の限界に挑んだ話
 Next.jsのIncremental Static RegenerationをVercel以外でやってみる

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T20:44:39+09:00

React+Material-uiでページ内リンクを実現する

はじめに

タイトルの通りです。
React+Material-uiでWebサイトを作成していて、ページ内でひゅっとリンクするあれを作りたかったのですが、少し悩んだのでメモ程度に残します。

ページ内リンクの基本

HTML+CSSでページ内リンクを実装する方法は以下の通りです。
ジャンプ先のオブジェクトにidを設定します
<p id="to"></p>
ジャンプしたいオブジェクトにhrefを記載します
<a href="#to">ジャンプする！</a>
Reactでの書き方

これをReactで書くとこうなります。
App.tsx
<p id="to"></p>
App.tsx
  <Button
    onClick={() => {
      window.location.href = "#id";
    }}
  >
    ジャンプする！
  </Button>;
window.location.hrefでボタンでリンク遷移ができます。
ここにジャンプ先のidを指定するとOKです

最後に

React+Material-uiと書きましたが、Material-uiはそんなに関係ないですね。
Reactでの書き方でした。以上です。

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T20:00:05+09:00

reactで条件にあった時に特定のclassを付与する書き方

今回、reactでclassNameを動的に付与させたいと思ったので、調べたことを備忘録として残しておきます。

書き方

共通のクラス名を付与しない場合

① true or false で違うクラス名を付与する
<p className={completed? "completed" :"incomplete"}>
   hoge
</p>
この場合、trueならcompletedが、falseならincompleteが付与されます。

② falseの場合はクラス名なし、trueの時に１つだけクラス名を付与
※false時にクラス名を付与したい場合はコロンの右側にクラス名を記載する
<p className={completed? "completed" :""}>
   completed  
</p>
③ falseの場合はクラス名なし、trueの時に2つ以上クラス名を付与
※false時にクラス名を付与したい場合はコロンの右側にクラス名を記載する
<p className={completed? "completed hoge" :""}>
   completed  
</p>
この場合は通常のクラス名の記載方法と同じで半角スペースを開けて記載すればOK

どちらにも共通のクラス名を付与した上で、+αで条件によってクラス名を付与したい場合
<p className={`item ${completed? "completed" :""}`}>
   completed  
</p>
この場合、completedがtrueでもfalseでもクラス名itemは付与されます。
バッククオートで全体を囲み、条件分岐の箇所を${}で囲ってあげればOKです。条件分岐の書き方に関しては今までの書き方と同じです。

+を使って以下のように書くこともできます。
<p className={'item ' + (completed? "completed" :"")}>
   completed  
</p>
気をつけるポイントとしてはitemの後に半角を入れる必要があります。
もし、半角を入れずに、completedがtrueになった場合、クラス名がitemcompletedとなってしまい、思うようにCSSが適用されなくなってしまいます。

以上、動的にクラス名を付与したいときの書き方でした！

参考記事

【JS】ReactのclassNameの色々な書き方紹介

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T19:52:32+09:00

VSCode + TypeScript + React で開発を行う人のための ESLint + Prettier の環境構築 2021

はじめに

前提として VSCode と Node.js のインストールが済んでいるものとします．
次の内容を実行すれば，カレントディレクトリに ts-react-project という名前で React のプロジェクトを作成できます．
ターミナル
npx create-react-app ts-react-project --template typescript
この状態でも TypeScript + React による開発は十分に可能です．しかし複数人でコードを書く際は，開発効率の維持という観点からソースコードの一貫性も重要になるため，コードの書式を整形・統一するツールを利用することが多いです．ここでは JavaScript/TypeScript の linter（コードの静的解析を行い問題部分をチェックするツール）である ESLint と，フォーマッタ（コードの整形を設定に沿って自動で行うツール）である Prettier を導入して環境構築を行います．
ESLint と Prettier の連携について調べると多くのページがヒットしますが，ややこしかったり，現在は非推奨なやり方で説明しているものもあって非常に悩ましいです．そこで VSCode で環境構築する手順について，2021年2月現在で最善と思われるものを備忘録としてまとめてみました．参考になれば幸いです．

ESLint の導入

1. ESLint 本体について

通常は yarn add eslint --dev によってインストールしますが，今回は create-react-app でプロジェクトを作成した際に ESLint が導入されています．バージョンの確認は eslint -v or eslint --version で可能ですが，
ターミナル
npm ls eslint
とすると，バージョンだけでなく，プロジェクトフォルダ内の node_modules に ESLint があることが確認できます．

2. 拡張機能の追加

VSCode 拡張機能「 ESLint 」を追加します．このプラグインによって， VSCode の「設定」から ESLint のセッティングが可能です．

3. ESLint の設定

node_modules/.bin/eslint --init を実行します（ VSCode のコマンドパレットを開き ESLint: Create ESLint Configuration を実行するのと同じ）．次のように入力していくと .eslintrc.js と package.json が作成されます．

特に気をつけなければならないのは

Which framework does your project use?: 今回は React を選択（ Vue もある）．

Does your project use TypeScript?: Yes

What format do you want your config file to be in?: .json の形式で設定することもできますが，今回は .js の場合を説明します．

Would you like to install them now with npm?: No

入力を終えるとプロジェクトフォルダの中に .eslintrc.js が作成されるので，以下のようになっているか確認します．
.eslintrc.js
module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 12,
    sourceType: "module",
  },
  plugins: ["react", "@typescript-eslint"],
  rules: {},
 };
試しに rules の部分を
{
  rules: {
    quotes: ['error', 'double'],
  }
}
として，ダブルクオーテーションでないとエラーが出るように設定してみましょう．写真のようになれば， ESLint が動いていることが確認できるはずです．

また ESLint の設定は .eslintrc.js でなされているので，package.json の eslintConfig の部分は削除します（残しておいた場合も .eslintrc.js の方の設定が優先されます）．
package.json
{
  ...,
  "eslintConfig": {  //削除
    "extends": "react-app"
  },
  ...,
}
Prettier の導入

1. Prettier のインストール
ターミナル
yarn add --dev prettier
2. 拡張機能の追加

VSCode の拡張機能「 Prettier - Code formatter 」を追加します．

3. .prettierrc の作成・記述

VSCode のコマンドパレットから Prettier: Create Configuration File，又は
ターミナル
echo {}> .prettierrc
を実行し，Prettier の設定ファイルである .prettirrc をプロジェクトフォルダ内に作成します．
記述の際は Prettier の Options にて設定可能なオプションが説明されているので参考にします．例：
.prettierrc
{
  "printWidth": 100,
  "trailingComma": "es5"
}
ESLint と Prettier の連携

連携させる際に考えるべきは次の二つです．
1. コーディング中は ESLint と Prettier を定期的に実行する．
2. ESLint にもコード整形のルールがあるため，それらを off にして Prettier との競合を防ぐ．

1 についてはユーザー側でいちいち気をつけるのは面倒なので，ファイル保存時に自動で走るように VSCode の設定を行います¹．2 については eslint-config-prettierというパッケージをインストールすることで解決できます．

1. VSCode の設定

settings.json に次の内容²を加えます．
settings.json
{
  "[typescript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode" // formatter: prettier
  },
  "editor.formatOnSave": true, // format by prettier when saving a file
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true // execute ESLint when saving a file
  }
}
2. eslint-config-prettier のインストール・適用
ターミナル
yarn add --dev eslint-config-prettier
を実行します．インストールの完了後，.eslintrc.js の "extends" を以下のように書き加えて保存します．
.eslintrc.js
{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended", //no-unused-varsのエラーを非表示にするために追加
    "prettier", // configを参照するために追加
  ],
}
3. 動作確認

app.tsx に適当にスペースを加えたり，セミコロンを抜いたりしてフォーマットを乱してみてください．保存した際に自動整形されれば ESLint と Prettier が動いていることが確認できます．

参考資料

日本語で書かれた各種 Web サイトだけでなく公式のドキュメントも参照する方が良い（サイトによって情報が曖昧だったり，そもそも情報の移り変わりが激しいため，かつて取られた方法が非推奨になっているケースがあるから）です．調べた中で参考になると感じた記事を示します．

Prettier 入門～ ESLint との違いを理解して併用する～
Prettier と ESLint の違い，併用する意義について分かりやすくまとめられています．

ESLint の Plugin と Extend の違い

Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった
ESLint の設定や Prettier との連携について悩んでいた際，非常に参考になりました．

TypeScript のプロジェクトに ESLint と Prettier を導入する方法（+VSCode での設定）
今回 VSCode で環境構築を行う際に参考にしました．

ESLint: Getting Started with ESLint

Prettier: Install
公式のドキュメントです．

自動化にあたっては ESLint から Prettier を呼び出すためのプラグイン，eslint-plugin-prettier もインストールして，ESLint から一括でコードの解析・整形を行う方法がメジャーでした．しかし直接 Prettier を実行するよりも遅かったり，レイヤーの不整合が起こりうるという問題もあるため，現在この方法は推奨されていません（ソース：Integrating with Linters - Prettier）．そのためここでは eslint-plugin-prettier はインストールせず，ESLint と Prettier を別々で実行するやり方を取ります． ↩

ここでは Prettier を TypeScript 入力時のコードフォーマッタとして指定し， editor.formatOnSave によってファイル保存時に実行されるように設定します．一方，ESLint をファイル保存時に実行する場合は editor.formatOnSave ではなく editor.codeActionsOnSave で設定することが推奨されています（引用は VSCode ESLint Extention の eslint.format.enable より）． ↩

Although you can also use the formatter on save using the setting editor.formatOnSave it is recommended to use the editor.codeActionsOnSave feature since it allows for better configurability.

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T19:52:32+09:00

VSCode + TypeScript + React で開発を行うための ESLint + Prettier の環境構築 2021

はじめに

前提として VSCode と Node.js のインストールが済んでいるものとします．
React のプロジェクトを TypeScript 用に作成するだけなら，次のコマンドを実行するだけで完了です．カレントディレクトリに ts-react-project という名前でフォルダが新たに作成されます．
ターミナル
npx create-react-app ts-react-project --template typescript
この状態でも TypeScript + React による開発は十分に可能です．しかし複数人でコードを書く際は，開発効率の維持という観点からソースコードの一貫性も重要になるため，コードの書式を整形・統一するツールを利用することが多いです．ここでは JavaScript/TypeScript の linter（コードの静的解析を行い問題部分をチェックするツール）である ESLint と，フォーマッタ（コードの整形を設定に沿って自動で行うツール）である Prettier を導入して環境構築を行います．
ESLint と Prettier の連携について調べると多くのページがヒットしますが，ややこしかったり，現在は非推奨なやり方で説明しているものもあって非常に悩ましいと思います．そこで VSCode で環境構築する手順について，2021年2月現在で最善と思われるものを備忘録としてまとめてみました．参考になれば幸いです．

ESLint の導入

1. ESLint 本体について

通常は yarn add eslint --dev によってインストールしますが，今回は create-react-app でプロジェクトを作成した際に ESLint が導入されています．バージョンの確認は eslint -v or eslint --version で可能ですが，
ターミナル
npm ls eslint
とすると，バージョンだけでなく，プロジェクトフォルダ内の node_modules に ESLint があることが確認できます．

2. 拡張機能の追加

VSCode 拡張機能「 ESLint 」を追加します．このプラグインによって， VSCode の「設定」から ESLint のセッティングが可能です．

3. ESLint の設定

node_modules/.bin/eslint --init を実行します（ VSCode のコマンドパレットを開き ESLint: Create ESLint Configuration を実行するのと同じ）．次のように入力していくと .eslintrc.js と package.json が作成されます．

特に気をつけなければならないのは

Which framework does your project use?: 今回は React を選択（ Vue もある）．

Does your project use TypeScript?: Yes

What format do you want your config file to be in?: .json の形式で設定することもできますが，今回は .js の場合を説明します．

Would you like to install them now with npm?: No

入力を終えるとプロジェクトフォルダの中に .eslintrc.js が作成されるので，以下のようになっているか確認します．
.eslintrc.js
module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 12,
    sourceType: "module",
  },
  plugins: ["react", "@typescript-eslint"],
  rules: {},
 };
試しに rules の部分を
{
  rules: {
    quotes: ['error', 'double'],
  }
}
として，ダブルクオーテーションでないとエラーが出るように設定してみましょう．写真のようになれば， ESLint が動いていることが確認できるはずです．

また ESLint の設定は .eslintrc.js でなされているので，package.json の eslintConfig の部分は削除します（残しておいた場合も .eslintrc.js の方の設定が優先されます）．
package.json
{
  ...,
  "eslintConfig": {  //削除
    "extends": "react-app"
  },
  ...,
}
Prettier の導入

1. Prettier のインストール
ターミナル
yarn add --dev prettier
2. 拡張機能の追加

VSCode の拡張機能「 Prettier - Code formatter 」を追加します．

3. .prettierrc の作成・記述

VSCode のコマンドパレットから Prettier: Create Configuration File，又は
ターミナル
echo {}> .prettierrc
を実行し，Prettier の設定ファイルである .prettirrc をプロジェクトフォルダ内に作成します．
記述の際は Prettier の Options にて設定可能なオプションが説明されているので参考にします．例：
.prettierrc
{
  "printWidth": 100,
  "trailingComma": "es5"
}
ESLint と Prettier の連携

連携させる際に考えるべきは次の二つです．
1. コーディング中は ESLint と Prettier を定期的に実行する．
2. ESLint にもコード整形のルールがあるため，それらを off にして Prettier との競合を防ぐ．

1 についてはユーザー側でいちいち気をつけるのは面倒なので，ファイル保存時に自動で走るように VSCode の設定を行います¹．2 については eslint-config-prettierというパッケージをインストールすることで解決できます．

1. VSCode の設定

settings.json に次の内容²を加えます．
settings.json
{
  "[typescript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode" // formatter: prettier
  },
  "editor.formatOnSave": true, // format by prettier when saving a file
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true // execute ESLint when saving a file
  }
}
2. eslint-config-prettier のインストール・適用
ターミナル
yarn add --dev eslint-config-prettier
を実行します．インストールの完了後，.eslintrc.js の "extends" を以下のように書き加えて保存します．
.eslintrc.js
{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended", //no-unused-varsのエラーを非表示にするために追加
    "prettier", // configを参照するために追加
  ],
}
3. 動作確認

app.tsx に適当にスペースを加えたり，セミコロンを抜いたりしてフォーマットを乱してみてください．保存した際に自動整形されれば ESLint と Prettier が動いていることが確認できます．

参考資料

日本語で書かれた各種 Web サイトだけでなく公式のドキュメントも参照する方が良い（サイトによって情報が曖昧だったり，そもそも情報の移り変わりが激しいため，かつて取られた方法が非推奨になっているケースがあるから）です．調べた中で参考になると感じた記事を示します．

Prettier 入門～ ESLint との違いを理解して併用する～
Prettier と ESLint の違い，併用する意義について分かりやすくまとめられています．

ESLint の Plugin と Extend の違い

Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった
ESLint の設定や Prettier との連携について悩んでいた際，非常に参考になりました．

TypeScript のプロジェクトに ESLint と Prettier を導入する方法（+VSCode での設定）
今回 VSCode で環境構築を行う際に参考にしました．

ESLint: Getting Started with ESLint

Prettier: Install
公式のドキュメントです．

自動化にあたっては ESLint から Prettier を呼び出すためのプラグイン，eslint-plugin-prettier もインストールして，ESLint から一括でコードの解析・整形を行う方法がメジャーでした．しかし直接 Prettier を実行するよりも遅かったり，レイヤーの不整合が起こりうるという問題もあるため，現在この方法は推奨されていません（ソース：Integrating with Linters - Prettier）．そのためここでは eslint-plugin-prettier はインストールせず，ESLint と Prettier を別々で実行するやり方を取ります． ↩

ここでは Prettier を TypeScript 入力時のコードフォーマッタとして指定し， editor.formatOnSave によってファイル保存時に実行されるように設定します．一方，ESLint をファイル保存時に実行する場合は editor.formatOnSave ではなく editor.codeActionsOnSave で設定することが推奨されています（引用は VSCode ESLint Extention の eslint.format.enable より）． ↩

Although you can also use the formatter on save using the setting editor.formatOnSave it is recommended to use the editor.codeActionsOnSave feature since it allows for better configurability.

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T18:57:59+09:00

Next.js, tailwindcssでウェブアプリを作りvercelでhostingする手順

手順

yarn create next-app

touch tsconfig.json でtsconfig.jsonを作る

yarn add --dev typescript @types/react @types/nodeでTSをインストール

yarn devを実行しtsconfig.jsonの中身が自動生成される

yarn add tailwindcss@latest postcss@latest autoprefixer@latestでtailwindcssを入れる

npx tailwindcss init -pでtailwindcssをinitialize

tailwind.config.jsのpurgeをこうするpurge: ['./pages/**/*.{js,ts,jsx,tsx}', './components/**/*.{js,ts,jsx,tsx}'],

.jsファイルを.tsxに変える

_app.tsxのglobal styleのimportをimport "tailwindcss/tailwind.css";に変える

globals.cssを削除する

https://paulintrognon.fr/blog/typescript-prettier-eslint-next-js ここにあるlinterの設定の仕方の手順を行う

tsconfig.jsonでstrictモードをオンにする
{
  "compilerOptions": {
    // ...
    "strict": true,
    // ...
yarn add --dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-jsx-a11yでes lintをインストール

.eslintrc.jsファイルを作り下記を入れる
module.exports = {
  root: true,
  env: {
    node: true,
    es6: true,
  },
  parserOptions: { ecmaVersion: 8 }, // to enable features such as async/await
  ignorePatterns: ['node_modules/*', '.next/*', '.out/*', '!.prettierrc.js'], // We don't want to lint generated files nor node_modules, but we want to lint .prettierrc.js (ignored by default by eslint)
  extends: ['eslint:recommended'],
  overrides: [
    // This configuration will apply only to TypeScript files
    {
      files: ['**/*.ts', '**/*.tsx'],
      parser: '@typescript-eslint/parser',
      settings: { react: { version: 'detect' } },
      env: {
        browser: true,
        node: true,
        es6: true,
      },
      extends: [
        'eslint:recommended',
        'plugin:@typescript-eslint/recommended', // TypeScript rules
        'plugin:react/recommended', // React rules
        'plugin:react-hooks/recommended', // React hooks rules
        'plugin:jsx-a11y/recommended', // Accessibility rules
        'prettier/@typescript-eslint', // Prettier plugin
        'plugin:prettier/recommended', // Prettier recommended rules 
      ],
      rules: {
        // We will use TypeScript's types for component props instead
        'react/prop-types': 'off',

        // No need to import React when using Next.js
        'react/react-in-jsx-scope': 'off',

        // This rule is not compatible with Next.js's <Link /> components
        'jsx-a11y/anchor-is-valid': 'off',

        // Why would you want unused vars?
        '@typescript-eslint/no-unused-vars': ['error'],

        // I suggest this setting for requiring return types on functions only where useful
        '@typescript-eslint/explicit-function-return-type': [
          'warn',
          {
            allowExpressions: true,
            allowConciseArrowFunctionExpressionsStartingWithVoid: true,
          },
        ],
        'prettier/prettier': ['error', {}, { usePrettierrc: true }], // Includes .prettierrc.js rules
      },
    },
  ],
}
yarn add --dev prettier eslint-plugin-prettier eslint-config-prettierでprettierをインストール

.prettierrc.jsを作り下記を入れる
module.exports = {
  // Change your rules accordingly to your coding style preferences.
  // https://prettier.io/docs/en/options.html
  semi: false,
  trailingComma: 'es5',
  singleQuote: true,
  printWidth: 100,
  tabWidth: 2,
  useTabs: false,
}
VS Codeのsettings.jsonにこれを追加(なければ)
{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}
package.jsonのscriptにこれらを追加
"lint": "eslint . --ext js,jsx,ts,tsx --fix && tsc --project tsconfig.json --pretty --noEmit"
yarn add --D husky@4.8.3 lint-stagedでhuskyとlint-stagedをインストール

package.jsonにこれを追加
  "lint-staged": {
    "src/**/*.{ts,tsx}": "npm run lint:fix"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T17:57:07+09:00

DjangoとReact redux TypeScriptを使ってオリジナルアプリを作ってみました（TwitterAPI）その1

まず私について

初めまして。

今回がQiita初投稿となります。

kenshoと申します。
2019年からプログラミングの勉強を本格的に始めて、web制作フリーランスを経験、その後はIT企業のインターンで働きながら独学でwebエンジニアの勉強をしていました。
2021年4月から新卒で上場企業のwebエンジニアとして働く予定です。

Qiitaを始めた理由は三つあります。
・自身がつまづいたところを共有することで他の学習者達の役に立ちたい
・学習のアウトプットができること
・自身の影響力を磨いていきたい

です。
初投稿なのと、まだまだ未熟エンジニアということもあり、言葉足らずや知識不足な点もあるかと思いますが、この発信が少しでも多くのプログラミング学習の参考になると幸いです。
ではいきましょう

オリジナルアプリ概要

git↓
https://github.com/kenshow-blog/twitter

登録画面↓

ログイン画面↓

ログインすると....

Mediaルームへ行く...

ここのinputにTwitter上のスクリーンネームを入力する
今回は「tokimeki_cafe」さんのスクリーンネームを入力
（https://twitter.com/tokimeki_cafe）

ロードが開始されバックサイドでそのアカウントの画像収集が始まる

画像のように画像収集に無事成功しました?

機能詳細

ログイン・・・メールアドレスとpasswordを入力

登録機能・・・ニックネーム、メールアドレス、passwordを入力して登録

ホーム画面・・・react、redux-toolkit,typescriptで実装。今後は「Media」ボタン以外にもボタンを作成して、TwitterAPIでいろいろな機能が実装できるアプリにしていく予定。

メディア画面・・・・主にmaterial-uiを使用してinput、button等を開発。またcollectionのスクリーンネームの隣にある「DEL」ボタンを押すと、「本当に削除しますか？？」のダイアログが表示されてYesを押すと、そこに収集された画像が全て削除されるようになってる

メディア個別画面・・・こちらもmaterial-uiのGridを使って横3列のきれいな画像一覧ページを実装しました。こちらの「DEL」を押すと指定した画像だけが削除されます。

使用言語、ライブラリ
python3
django(django-rest-frame-work)
react
redux-toolkit
TypeScript
開発に至った経緯

３つあります
・モダンな開発方式でオリジナルアプリを作ることでwebエンジニアとしてのスキルをあげたかったから
・APIを組み込んだアプリ開発にチャレンジしてみたかった
・自分が機械学習などに興味があり、その中でも画像認識の技術について学んでいく際にこれで収集した画像が役に立つと思ったから

アプリ構造

バックエンドディレクトリ構造図（django)
twitter
├── auth_api #ユーザーのアカウントを管理するところ
│   ├── __init__.py
│   ├── __pycache__
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── serializers.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── manage.py
├── media
│   └── media
│       ├── 収集した画像が入る
│
├── media_api #TwitterAPIを叩いて画像を収集し、保存をしてくれるところ
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-38.pyc
│   │   ├── admin.cpython-38.pyc
│   │   ├── apps.cpython-38.pyc
│   │   ├── config.cpython-38.pyc
│   │   ├── models.cpython-38.pyc
│   │   ├── serializers.cpython-38.pyc
│   │   ├── urls.cpython-38.pyc
│   │   └── views.cpython-38.pyc
│   ├── admin.py
│   ├── apps.py
│   ├── config.py #APIキーを格納しておくファイル
│   ├── migrations
│   ├── models.py 
│   ├── serializers.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
└── twitter
    ├── __init__.py
    ├── __pycache__
    │   ├── __init__.cpython-38.pyc
    │   ├── settings.cpython-38.pyc
    │   ├── urls.cpython-38.pyc
    │   └── wsgi.cpython-38.pyc
    ├── asgi.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py
モデル

ユーザーモデル
ーーーーusername
ーーーーemail
ーーーーpassword

イメージポストモデル

ユーザーとスクリーンネームとの紐付けのために作成
ーーーーscrName（スクリーンネーム）
ーーーーuserPost(外部キー。ユーザーモデルとの結びつけ）
ーーーーcreated_on(作成日)

Imagesモデル
収集した画像らを保存し、イメージポストモデルとの紐付けのために作成
ーーーーuserImg（外部キー。ユーザーモデルとの紐付け）
ーーーーimgs(収集した画像）
ーーーーimgPost(外部キー。集取した画像とイメージポストとの紐付け
ーーーーcreated_on(作成日)

参照した記事↓
https://qiita.com/xKxAxKx/items/60e8fb93d6bbeebcf065

ユーザーモデルコード↓
twitter/auth_api/models.py
from django.db import models
from django.contrib.auth.models import BaseUserManager, AbstractBaseUser, _user_has_perm
from django.core import validators
from django.utils.translation import ugettext_lazy as _
from django.utils import timezone


class AccountManager(BaseUserManager):
    def create_user(self, request_data, **kwargs):
        now = timezone.now()
        if not request_data['email']:
            raise ValueError('Users must have an email address.')


        user = self.model(
            username=request_data['username'],
            email=self.normalize_email(request_data['email']),
            #normalize_emailで受け取ったデータがemailであるかをチェックしている
            is_active=True,
            last_login=now,
            date_joined=now,
        )

        user.set_password(request_data['password'])
        user.save(using=self._db)
        return user

    def create_superuser(self, username, email, password, **extra_fields):
        request_data = {
            'username': username,
            'email': email,
            'password': password
        }

        user = self.create_user(request_data)
        user.is_active = True
        user.is_staff = True
        user.is_admin = True
        user.save(using=self._db)
        return user


class Account(AbstractBaseUser):
    username = models.CharField(_('username'), max_length=30, unique=True)
    first_name = models.CharField(
        _('first name'), max_length=30, blank=True)
    last_name = models.CharField(_('last name'), max_length=30, blank=True)
    email = models.EmailField(
        verbose_name='email address', max_length=255, unique=True)
    is_active = models.BooleanField(default=True)
    is_staff = models.BooleanField(default=False)
    is_admin = models.BooleanField(default=False)
    date_joined = models.DateTimeField(
        _('date joined'), default=timezone.now)

    objects = AccountManager()

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['username']

    def user_has_perm(user, perm, obj):
        return _user_has_perm(user, perm, obj)

    def has_perm(self, perm, obj=None):
        return _user_has_perm(self, perm, obj=obj)

    def has_module_perms(self, app_label):
        return self.is_admin

    def get_short_name(self):
        return self.first_name

    @property
    def is_superuser(self):
        return self.is_admin

    class Meta:
        db_table = 'auth_user'
        swappable = 'AUTH_USER_MODEL'
USERNAME_FIELDをemailに上書きすることでログインを通常ユーザー名、パスワードであるところをemail、パスワードにカスタマイズができる

イメージポスト、Imagesモデルコード↓
twitter/media_api/models.py
from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
from django.conf import settings

#下記は収集した画像の名前を変更して保存するための関数
def upload_post_path(instance, filename):
    ext = filename.split('.')[-1]
    return '/'.join(['media', str(instance.userImg)+'_'+str(instance.imgPost.scrName)+'_'+str(instance.id)+str(".")+str(ext)])

class ImagePost(models.Model):
    scrName = models.CharField(max_length=100)
    userPost = models.ForeignKey(
        settings.AUTH_USER_MODEL, related_name='userPost',
        on_delete=models.CASCADE
    )
    created_on = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.scrName



class Images(models.Model):
    id = models.AutoField(primary_key=True)
    userImg = models.ForeignKey(
        settings.AUTH_USER_MODEL, related_name='userImg',
        on_delete=models.CASCADE
    )

    imgs = models.ImageField(blank=True, null=True,upload_to=upload_post_path)
    imgPost = models.ForeignKey(
        ImagePost, on_delete=models.CASCADE
    )


    def __str__(self):
        return str(self.userImg)+'_'+str(self.imgPost)+'_'+str(self.id)
イメージポスト、Imagesモデルについての考察

取得したいユーザーのスクリーンネームに対して、収集する画像は複数であるため、1対多の関係になることが予想できた。
そのため、コードを記述する段階で、ユーザーのスクリーンネーム用のモデルと、収集する画像用のモデルの、2つを作成すれば良いと考えた。

settings

認証についてはJWTを採用
理由としては下記
・　安全 JWTに署名が含まれているため、改ざんがあってもチェックできるようになっている。
・　実装のしやすさセキュアなToken発行が楽に実装できる。
・　管理のしやすさ URLに含むことができる文字で構成されているから、HTTPリクエストでの取り扱いが楽。

これらに加え、実務でも採用されることが多いということを風の噂で耳にしたことがあったので、この際使ってみようと思いました。
参考記事↓
https://qiita.com/Syoitu/items/bc32b5e1c2fa891c2f96
twitter/twitter/settings.py
import django
from pathlib import Path
import os
# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/3.1/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'シークレットキー'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
     #追記したもの↓
    'corsheaders',
    'rest_framework',
    'media_api.apps.MediaApiConfig',#media_api
    'auth_api.apps.AuthApiConfig',#auth_api
    'djoser',
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',#←追記
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

#フロントのreactとのやりとりを可能にするため↓
CORS_ORIGIN_WHITELIST = [
    'http://localhost:3000'
]

#JWT認証
JWT_AUTH = {
    'JWT_VERIFY_EXPIRATION':  False,
    'JWT_AUTH_HEADER_PREFIX': 'JWT',
}


ROOT_URLCONF = 'twitter.urls'

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]


REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
    ],
    'NON_FIELD_ERROS_KEY': 'detail',
    'TEST_REQUEST_DEFAULT_FORMAT': 'json'
}

WSGI_APPLICATION = 'twitter.wsgi.application'


# Database
# https://docs.djangoproject.com/en/3.1/ref/settings/#databases

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}


# Password validation
# https://docs.djangoproject.com/en/3.1/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]


# Internationalization
# https://docs.djangoproject.com/en/3.1/topics/i18n/

LANGUAGE_CODE = 'en-us'

TIME_ZONE = 'Asia/Tokyo'#←これにすると日本時間をデフォルトにしてくれる

USE_I18N = True

USE_L10N = True

USE_TZ = True


# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/3.1/howto/static-files/

AUTH_USER_MODEL = 'auth_api.Account'

STATIC_URL = '/static/'
#↓下記を記述してtwitter/media/media/に画像を保存できるようにしている
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'
AUTH_USER_MODELで自分が作ったユーザーapiを参照させることで独自に定義したユーザーモデルをdjango側に認識させることができる
参考記事↓
https://djangobrothers.com/blogs/referencing_the_user_model/

プロジェクトのurlを通す
twitter/url.py
from django.conf.urls import url
from django.conf.urls.static import static
from django.conf import settings
from django.urls import path, include
from django.contrib import admin

import django
import os
import sys

sys.path.append('twitterまでの絶対path')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'twitter.settings')
django.setup()

from rest_framework_jwt.views import obtain_jwt_token
urlpatterns = [
    path('admin/', admin.site.urls),
    path('media_api/', include('media_api.urls')),
    path('login/', obtain_jwt_token),
    path('api/', include('auth_api.urls'))

]

urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
from rest_framework_jwt.views import obtain_jwt_token
を記述したときになぜかこのライブラリを参照してくれないエラーが起きたので下記をこのライブラリをimportする前に追記したところ解決しました。
import django
import os
import sys

sys.path.append('twitterまでのpath')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'twitter.settings')
django.setup()
原因は、まだ理解できていないのですが、わかったら別の記事で発信します?
（わかる方いたらコメントお願いします?‍♂️）

ここまでの感想

ユーザーモデルの構築は、結構苦戦しました笑
ログインをemailとパスワードにしたいというこだわりがあったのでその分djangoのユーザーモデルを自分でカスタマイズしなければならなかったので、、、?

次回は、
auth_apiのserializer,view
media_apiのserializer,view
の構築を発信していきます！
ここまで読んでくださりありがとうございました！?‍♂️

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T14:13:23+09:00

【未経験】独学＋メンターでここまで出来た！Web知識ゼロからモダンな技術アプリ開発までに利用した5つのサービス【Rails / React / AWS / Docker / CircleCI】

0. はじめに

こんにちは！辻野(@ddpmtcpbr)と申します。

当記事は、「Webエンジニアへのキャリアチェンジを目指している開発未経験者が、モダンな技術を備えたアプリを開発するまでの学習過程」についてまとめたものです。

現在筆者は非IT系企業の社員として働いており、Web開発エンジニアとしての実務経験はありません。

そんな筆者がWebエンジニアとしてのキャリアチェンジをするためのポートフォリオとして、本アプリを開発しました。

学習開始から現時点までにおいて、プログラミングスクール等には通っておらず、学習はほぼ全て独学&一部メンターサービス利用の布陣で進めてきました。

独学中心でアプリ開発に挑戦したい、ポートフォリオを作成してWebエンジニアへのキャリアチェンジを進めていきたい、と考えている方々にとって、参考になればと思います。

最初に、今回私が開発したアプリの概要を紹介します。

アプリ名：積読解消アプリ「Yomukatsu!」

「あなたの積読解消をサポートします」をスローガンに掲げたSPA風Webアプリです(”風”の詳細は後述)。

読書メンタルマップという手法を用いて、ユーザーの書籍完読に向けたモチベーション維持をサポートします。

Web URL: https://yomukatsu.com/

【3分動画】Yomukatsu 字幕解説

アプリの使い方を3分でまとめています。

使用技術

Backend: Rails ( API mode / Rspec / rubocop) + Nginx ( upstream puma-socket )

Frontend: React ( create-react-app / Redux / Material-UI / eslint&prettier)

Infra: AWS ( ECS Fargate/ ECR / RDS / ALB / Route53 ), Netlify, Docker&docker-compose, CircleCI

各項目の詳細は後述しています。

インフラ構成

モダンな技術を採用したWeb系企業が提供している、中・大規模なアプリケーションを想定したインフラ構成にしています（そのため、個人開発アプリとしてみるとちょっと仰々しいかもです(;’∀’)）

詳細は後述しています。

機能一覧

ユーザー利用機能

Twitterアカウントを利用したユーザー登録(OAuthによるSNS認証)

ゲストログイン機能

Google Books APIを用いた書籍検索機能

Google Books、Amazon、楽天ブックスへのリンクボタン配置

Twitterシェア機能

ハッシュタグ「#yomukatsu」付きTweet

Twitter card 表示

Twitter card用にリサイズした書籍画像をAWS S3へ保存・管理

Redux による state 管理を活用したローディング画面

Slack Incomming Webhookを利用したお問い合わせ機能

Route53 による独自ドメイン + SSL化

非ユーザー利用機能

Netlify の Pre-reidering 機能活用による動的なOGP情報の保持（ Twitter card 表示用）

Docker による開発環境の完全コンテナ化

CircleCI による自動 CI/CD パイプライン構築

CI: Rspec, rubocop, eslint&prettier

CD: AWS ECR

その他セキュリティ対策(XXS, CSPF等)

まず触ってみてもらうのが一番良いかと思います！今回はフロントエンドに React を採用しているため、メニューモーダルの開閉や通知バー表示など、アニメーション的な表現も実装できているのが伝わるかと思います。

ゲストユーザー機能もありますので、気軽に利用してみてほしいです！レスポンシブにも対応しています。(推奨ブラウザはChrome、Safariになります）

アプリURL: https://yomukatsu.com/

※現在α版としてのリリースのため、配信内容が予告無く変更される可能性がございます

あわせて、 Githubも公開していますので、よかったら参考にしてください。

Github URL: https://github.com/ddpmntcpbr/rails_react_docker

この記事について

当記事は3章構成になっております。

まず、「1.自己紹介」で、簡単に自己紹介をさせていただきます。

次に、「2.開発アプリ解説」で、今回の開発アプリ開発について、コンセプト決定の流れから、実装機能/技術スタックについて詳しく紹介します。「転職用PF作りたいけど、どんなアプリを作ればいいか分からない」という方にとって、参考になることがあれば幸いです。

最後に、「3. 学習ロードマップ」で、Web知識ゼロだった筆者が、当アプリの開発にまでに利用した5つの教材およびサービスについて、時系列に沿って紹介したいと思います。特に独学では、「まず何を学べば良いのか」「どんな教材を選べば良いのか」というところから自身で考える必要があります。そういった方々にとって参考になり得る情報と思います。

1. 自己紹介

1.1 筆者スペック

20代後半男

工学部機械系修士卒 → 非IT系日系製造業技術開発職(現職)

大学から現職において、データ分析ツールとしてプログラミングを経験(matlab / python)

Webエンジニアへのキャリアチェンジを目指し、社会人になってから独学を開始

大学入学以降、授業や研究データの分析ツールとしてプログラミングに触れる機会はありました。もともと自動化や効率化に興味があったことからプログラミングにだんだんとのめり込み、研究室ではプログラミングに多く触れられそうな研究テーマ(データ分析系)を選びました。

したがって、「プログラミング自体が完全に未経験」というわけではありませんでした。しかし、いわゆる”Web系”の知識は社会人以降の独学を開始するまではゼロ、という状態で、最初は HTML すら知らないところからのスタートでした(￣▽￣;)。そのため当記事では「Web知識ゼロ」という表現をしています。

キャリアチェンジ志望の理由は、ざっくりと言えば、

1. もっとプログラミングがしたい
2. モノづくりで誰かの役に立ちたい
3. 非効率・非生産的な仕事を無くしたい

ここについては当記事の趣旨ではないので、詳細については省略します。

2. 開発アプリ解説

2.1 コンセプト方針

転職用PFアプリのコンセプトを決めるにあたり、満たすべき用件としては、下記3点を考えました。

(a) 実際の企業が採用しているようなモダンな技術を盛り込む
(b) 具体的な解決課題を明確にする
(c) サービスの利用が個人で完結する

(a) 実際の企業が採用しているようなモダンな技術を採用する

未経験からエンジニア転職において、高品質なポートフォリオは必須と考えました。

「モダンな技術をポートフォリオに組み込むことで、技術力の高さをアピールする」というのが基本的な考え方になるとは思いますが、個人的な解釈としては、ポートフォリオで証明すべきは「技術力」ではなく「自走力」だと考えています。

ぶっちゃけた話、実際の現場を経験したエンジニアと比べれば、未経験者間での能力差というものはどんぐりの背比べのようなものだと思います。多くの企業が「実務経験1年以上」をエンジニアの採用項目にあげていることからも、実務経験というのはそれだけ重い価値があり、未経験者とは大きな隔たりがあるのだと思います。

したがって、ポートフォリオの技術レベルの高さそのものはあまり重要ではなく、そこに到達するまでの過程の方が大事であり、「自走力＝必要な情報は自らキャッチアップして吸収する能力」があることを示す方が、企業人事側としては採用しやすいのではないか？と考えました。

「スクールの制作アプリをそのまま提出する未経験者が足切りされてしまう」という話は多く聞きますが、これはそのアプリの技術力が低いからではなく、そのアプリから当人の「自走力」が主張できないから、だと私は考えています。私が独学ベースにこだわったのは、単純にお金の問題だけではなく、独学ベースでアプリを開発することができれば、自然とそれが「自走力の証明」につながると考えたからです。

今回のアプリにおいては、「独学:メンター=8:2」くらいの割合で、上記技術を採用できるラインまで行くことができています。「メンター利用は独学からは外れるのでは？」という指摘もあるかもしれませんが、

プログラミングでは、個人ではどうにもならないようなエラーに遭遇してしまうことが多々ある

実際に企業に入ってからは、先輩エンジニアの方々に分からないことを質問しながら業務を進めることになるため、「質問力」も重要な能力である

完全独学オンリーだと、誤った癖が身についてしまっているリスクが高くなる

といった観点から、独学者が適宜メンターサービスを利用することは、かえって採用人事側にとって安心感を与える材料になるのでは、と考えたので、自信を持って「メンターサービスを使いました」と主張しています。

※ 具体的なモダンな技術リスト

Rails API + JSフレームワーク(React.js)の構成

Dockerで実行環境を完全コンテナ化

Herokuではなく、AWS でアプリをデプロイ(ECS Fargate & ECR)

Circle CIによるCI/CDパイプラインの構築

(b) 具体的な解決課題を明確にする

さて、前章とは一見真逆のことを言いますが、アプリ開発において、モダンな技術を採用することそのものには本来何の価値もない、と考えています。

なぜなら、アプリの目的はあくまでも「ユーザーにとって価値を提供できるか」であり、技術はそれを実現するための手段でしかないはずだからです。(保守・運用面でのメリットも考えられますが、保守・運用の最終目的もユーザーへの価値提供であることから、この点も包含した解釈になります)

これは、技術というものを下に見ているというわけでは決してありません。むしろ「新しい技術をどんどん使ってみたい！」という技術に対する好奇心、探究心は人一倍強い自負があります。現職はIT系ではありませんが、技術開発職という立場で業務に取り組んでおり、知的好奇心を満たせるという意味では、今の仕事に面白みを感じています。

しかしながら、かつては行き過ぎた技術先行思想によって「手段の目的化」が発生し、「最新技術を駆使した誰にとっても役に立たない技術」を開発してしまったという苦い過去の経験があったりもします。結果として「やっぱり技術は人の役に立ってなんぼ」というのが、約3年間技術職として働いてきて培った、技術者としての小さな矜持だったりします(この辺の話は直接お会いした方にはお話できるかと思います)

転職用PFであれば、技術ありきな考え方になることはある程度は仕方がないことでしょう。しかし「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」くらいのことは転職用PF作成においても考えていいんじゃないかな？と思いました。あるいは、もう少し目線を下げて「自分が欲しいものを作ろう」という程度でも十分でしょう。大事なのは、まず課題があり、それを解決する手段として技術があるという順番だと思いました。

もちろん今回の開発アプリは転職用PFが趣旨である以上、中には「技術力を証明したいから」という理由で選定した技術もあり、全てに対して課題が明確だったわけではありません。また、初心者の個人開発アプリがいきなりバズることは現実的には厳しいとは思います。しかし、そこを目指す姿勢があるかというのは、エンジニアとして本格的にキャリアを進めていく上では、長期的には大きな差異になると考えています。

また、

課題が明確な方が採用した技術や実装した機能の根拠も明確にできるため、開発の方針を立てやすい

自身がユーザー目線に立てることで、改善点を見つけやすい

純粋にモチベーションを維持しやすい

といった点でもメリットもあると感じましたので、この方針は間違っていなかったと思います。

(c) サービスの利用が個人で完結する

「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」を、もう一歩深く考えた方針です。

例えば Rails を対象として考えたとき、一般的な転職用PFとしては、TwitterライクなSNS系アプリや、メルカリライクなEC系アプリが多いかと思います。

理由は、ユーザー認証、CRUD操作、DB間のリレーションなど、基本的なサーバーサイド技術を一通り抑えられるものであるから、だと思います。「Railsの一般的な知識を持っていることを証明する」手段と考えれば、妥当な方針でしょう。

しかしながら、未経験者が転職用に開発した上記アプリが実際にユーザーに継続して使われるということは、まず無いでしょう。SNS系アプリは「ユーザー数が多ければ多いほどサービスとして質が高まる」性質があるため、アプリとして軌道に載せること自体が非常に難しいです。EC系アプリは BtoC であれば出品企業がいないとサービスが成り立たない、CtoCであればより SNS として要素が強まる & いよいよメルカリで十分、という壁があります。

これらアプリの難しさは、ユーザーどうしがつながることを前提としている点にあります。裏を返せば「個人で完結するアプリであれば、活路はある」とも言えると考え、この方針でコンセプトを詰めていくことにしました。

2.2 コンセプト内容

上記3点を念頭に置きながら、自分自身の生活の中で"課題"を探し、最終的にたどり着いたものが「読書メンタルマップ術の電子化」というコンセプトでした。

そもそも皆様は、読書メンタルマップ術というものをご存知でしょうか？

読書メンタルマップ術とは、ハーバード大学の先生が提唱している積読解消術です。読破したい書籍に対して、

1. 完読したい本について、それを読む“理由”や“目的”を3つ、紙に書きだす
2. 飽きてきたら、それを見返す

を繰り返すことで、完読までモチベーションを維持するというシンプルな読書手法です。

積読というものは、だいたい「最初は読む気があったけど、次第に読む気がなくなってしまった」書籍です。この「最初の読む気」を事前に明文化・保存しておくことで、いつでも最初の頃に新鮮な気持ちを取り戻せるようにしておこう、というイメージになります。

自分自身、実際に活用している技術ではあるのですが、少し困ったことがあります。それは、電子書籍との相性が悪いことです。

通常であれば紙とペンを用いるものですが、例えば出先でスマホやタブレットで電子書籍を読んでいるような状況では、必ずしもこれらの道具があるとは限りません。特に私は、外に出る時はあまりものを多く持ちたく無い性分なので、外ではスマホと財布くらいしか持っていないことが多いです。

仮に持っていたとしても、例えば電車の中で紙とペンを出して色々と書き始めるのは、少し億劫だったりします。

「これを全部ペーパーレスで完結できるようなアプリがあったら便利だな」と思ったのが、このコンセプトを思いついたきっかけになっています。

もちろん、これだけであればスマホのメモ帳だけでもできてしまうものですが、このアプリには、

Google Books APIを活用した書籍検索・保存機能

メンタルマップ作成のヒント機能

Google Books, Amazon, 楽天ブックスへのリンクボタン配置(特に書籍レビューはメンタルマップ作成の大きなヒントになる)

Twitterでの読書仲間への気軽なシェア機能

といった機能が備わっており、より読書メンタルマップ術を使用しやすい環境を整えています。

先ほどの「2. 具体的な解決課題を明確にする」に照らし合わせて考えると、このアプリの解決課題は、ユーザーの積読を解消すること、もっと言えば、読書メンタルマップ術をペーパーレスで実行できるすることで電子書籍で読書するユーザーにとっても扱いやすくすること、になります。

また、「3. サービスの利用が個人で完結する」も満たしています。当アプリには、ユーザー同士がつながる機能は一切実装されていません。

代わりとして、Twitterとの連携にはかなり重きを置いて実装機能を決めました。具体的には、

Twitterアカウントを利用したユーザー登録

ワンタップでハッシュタグ付きツイート

充実した Twitter カード表示

を機能として実装しています。原則的には個人でサービスが完結しつつも、ユーザーどうしの繋がりはTwitter内の既存のネットワークに乗っかる、ことを狙ったコンセプトになっています。

2.3 技術スタック

再度、インフラ構成を載せます。

この内容について、ひとつひとつ解説します。

Back-end

Rails API + Nginx の組み合わせにしています。

サーバーサイドフレームワークとしては他にも Laravel, Django, Node.js などもあります。恐らく大体のことは、どれを選んでも実装・実現できる、と思うのですが、その中で今回 Rails を選んだ理由は、

採用している企業数が多い

日本語の教材が豊富なため学習のハードルが低い

国内コミュニティが発達しているため、インターネット上での日本語ドキュメントが豊富

最初の学習言語として Rails を選択する初学者の方は多くいるかと思います。その一方で、「Railsはオワコン」という説が各所で言われていることについて、不安に感じる初学者の方もいると思います。

この点に関して、あくまで個人的な見解を述べますと、初学者であった自分が、少なくとも最初に学ぶ言語/FW として Rails は間違いではなかった、と考えています。

正直、初学者である私には、「なぜ Rails がオワコンであるのか」について技術ベースで語ることはできません。しかし、

現時点で Rails を採用している企業の絶対数は多く存在すること

日本国内において、Rails に替わるサーバーサイドのデファクトスタンダードな技術が、まだ定まっていないこと

は事実と言ってよいかと思います。

もしかしたら、長期的に見れば日本国内でも Rails を採用する企業が減っていく流れにはあるのかもしれません。しかし、微分値と絶対値はセットで捉えないと判断を誤ることになります。初心者が目指すべきは「今すぐに仕事を得られる技術を身に着けること」であり「将来必要になってくる技術」ではない、自分が今学ぶべきはやはり Rails である、と判断をしました。

また、オワコンというのは裏を返せば、技術的に枯れていて、初心者にとっては学びやすい言語/FWである、とも言えます。

特に日本国内での(過去含めた)使用者が多いため、日本語のドキュメントが多く存在します。事実、Rails開発で遭遇するエラーは、Google検索すれば何かしらの日本語記事がヒットします。

最先端の技術は過去の技術の欠点を補う要素を持って生まれてきているのは事実ですが、検索しても欲しい情報が見つからなかったり、あったとしても英語ドキュメントだけだったりします。私自身は、このアプリの開発を通じてWebフレームワークに基本的な概念が身についてきているため英語でも大丈夫になってきましたが、ベースラインすら乏しい状態の初学者がいきなり英語のドキュメントを読み解いていくのは、二重にしんどいです。

以上が、私が最初の言語/FWとして Rails を選んだ根拠になります。

主要gem

devise_token_auth： APIモードでの devise。トークン認証を簡単に実装

twitter_omniauth：Twitter認証を簡単に実装

active_model_serializer： Rails APIからのレスポンスJSONを制御

imageMagic: 画像のリサイズを実行。特に、Twitter card用に書籍画像をリサイズする際に使用

aws-fog/carrierwave: リサイズした書籍画像を AWS S3 に保存

rspec：デファクトスタンダードになっているRubyテスト用フレームワーク

rubocop： Rubyの静的コード解析

TwitterアカウントでのOAuth認証は、過去の実装例が少なく、非常に苦労したところでもありました。しかし、「Twitterとの連携を重視」という今回のコンセプト上では絶対に欲しい機能と考え、頑張って実装しました。

AWS S3については元々採用予定はなかった(Google Books APIの画像リンクをそのまま引っ張ってくる予定だった)のですが、Twitter card で書籍画像を表示させる時にどうしても画像サイズを適切に制御する必要が出てきたので、imageMagic と合わせて Rails で画像リサイズ & S3保存、を実装することにしました。

Front-end

今回フロントエンドとしては、JSフレームワークであるReact.jsを採用しました(細かいこと言えば React はフレームワークではなくライブラリですが、ここではフレームワークとして扱います)。モダンな技術採用を謳う以上、Rails + jQuery/bootstrap の構成では心許ないと考えました。

JSフレームワークとしては、国内企業での採用状況から考えるに、React.jsかVue.jsか、の二択になると思います。その中でもReact.jsを選んだ理由は、

自分が調べた範囲では、バックエンドに Rails を採用している企業群のうち、フロントに React を採用している企業の割合が高かった

Vue.js よりも規約が厳格であり、初学者の自分であっても自然と可読性の高いコードを書くことができそう

たまたま、React を効率的に学べる良い教材を見つけた

特に最後については、第３章で後述しています。

アプリ開発を通じて React.js が割と気に入ってきたので良い選択だったとは思いますが、この点に関してはどちらを選んでも間違いではなかったかな、とは思います。

主要ライブラリ等

create-react-app: Facebookが提供するオープンソースのReact開発パッケージ

Redux: Stateの一元管理するフレームワーク。Redux関連ファイルは、reducksパターン則って管理

Redux-thunk: Redux state の非同期処理を制御

react-helmet: 動的なmetaタグの挿入によるOGP情報の保持(Twitter card用)

react-share: Twitter含めたSNSシェア用ボタンを簡単に配置

Material-UI ： Google が提供する UI コンポーネントライブラリ。簡単におしゃれな UI コンポーネントをアプリ内に配置できる

eslint & prettier: javascriptに対する静的コード解析。eslint は create-react-appに標準搭載されているものをベースに少しプラグインを追加 & prettier はイチから導入

今回はユーザーの利用シーンを考えると、Web上でもネイティブアプリのようにサクサク動く、JSリッチなアプリケーションにしたいと考えました。この点からも、jQuery+bootstrap ではなく React.js を採用してよかったと思います。

React の実装には、特にMaterial-UIが強力で、開閉モーダルや通知バー表示などのアニメーション演出や、ページ全体のレスポンシブ対応などがかなり簡単に実装できました。このライブラリを使えたというだけでも、React を採用した価値があったと思えるほどでした。

Infra

Docker/docker-compose

開発環境は、全てDockerコンテナ内で完結させています。docker-compose.ymlのサービス構成としては、

db: MySQL

api: Rails

web: Nginx

front: Node.js (React)

としています。

後述しますが、AWS ECS(Fargate)へのコンテナデプロイを利用することで、開発環境と本番環境の差異を小さくすることができています。

AWS(Amazon Web Service)

バックエンド( Rails + Nginx )のデプロイに使用。Railsチュートリアルなどではアプリの本番環境へのデプロイにはHerokuを用いることが一般的ですが「モダンな技術を採用したい」という観点から、AWSに挑戦しました。

稼働させるまでめちゃくちゃ苦労しました。ここを完全独学で完結させるのは相当しんどいと思います。第３章で触れていますが、AWSの学習については、メンターさんをかなり頼らせてもらいました。

※ 利用サービス

ECS (Fargate): コンテナ向けサーバーレスコンピューティングエンジン。この中に Rails と Nginx の Docker イメージを入れて稼働させる

ECR: Rails と Nginx の Docker イメージを保存しておくリポジトリ

RDS (MySQL): AWS が用意しているスケーラブルなデータベースエンジン

ALB: 負荷分散を担うロードバランシングサービス

Route53: サイトの独自ドメイン化に使用

ACM: サイトの https 化に使用

S3: 静的ホスティングサービス。書籍画像も保存・管理に使用

Netlify

フロントエンド(create-react-app)のホスティングで利用。

最初はバックエンドに合わせてフロントも AWS ( Amplify Console ) でホスティングしていたのですが、create-react-appはSPAとしてのアプリ開発となることから、metaタグ無いにOGP情報を保持できない = Twitterでページをシェアした時のカード表示を動的に制御できない、という問題が出てきました。

おそらくは AWS でも解決する手段はあると思うのですが、今回は Netlify の Pre-rendering機能を使うことで解決することにしました。この機能を使うことで、 create-react-app であっても、サーバー側で javascript をレンダリングしてからブラウザが解釈できるようになります（あと単純に、無料で利用できるのもメリット）

この問題にあたってから、最近ホットな React フレームワークの Next.js の有り難みが自然と分かるようになってきた( Next.js は SPA/SSG/SSRを選択可能 )のですが、今回はすでに開発を始めていたこともあり、create-react-app + Netlify の構成で最後まで開発しました。

CircleCI

国内ではデファクトスタンダードとされている、Saas型のCI/CDサービスです。今回CircleCIで自動化した処理は、

Rspec

rubocop

eslint&prettier

AWS ECR への Image push

AWS ECS のタスク&サービスの更新

Netlifyにはもともと自動デプロイ機能がついていることから、CircleCIを導入することで、Github上の master ブランチに merge しただけで、本番環境への再デプロイが完了する、という状態に持っていくことができました。

一度ありがたみが分かると、もう手放せないですね( ´ ▽ ` )

3. 学習ロードマップ

さて、いよいよ本題です。ここまでで開発したアプリについて解説をしてきましたが、ここからは、このアプリ開発に至るまでの学習過程をたどっていきます。

第1章でもお伝えした通り、筆者はプログラミング経験自体はあっても、いわゆる「Web系」の知識はゼロからのスタートでした。繰り返しますが、HTMLすら知らなかった状態から、独学ベースで上記技術スタックをアプリに盛り込めるレベルまで到達することができました。

独学ベースでの学習になると、「どの学習教材を選ぶべきか」というところから自分で考える必要があります。いろいろと紆余曲折ありましたが「これは役に立った！」と思うものを厳選し、時系列に沿ってお伝えします。

※下記サービスのWebリンクや、ロゴ画像、ホームページのスクリーンショットについては、事前に各運営者様に使用許可をいただいております。改めまして運営者皆様、利用快諾していただきありがとうございました。

3.1 Progate

皆大好きProgate。今からエンジニアを目指す方は、全員ここから入門して間違い無いでしょう。

URL: https://prog-8.com/

自分は手当たり次第に色々な講座をやってみていましたが、

HTML&CSS

Javascript(ES6)

jQuery

Ruby

Ruby on Rails

次いで

Command line

Git

SQL

辺りを押さえておけば十分だったかと思います。

各講座の序盤のレッスンは無料会員でも受けることができますが、本気でエンジニアを目指すのであれば、有料会員限定のコースも含めて取り組んでいきましょう。

これだけでもそれなりにボリュームはありますが、挫折しにくいよう学習ステップがかなり細かく設定されているので、初心者にとっても易しいつくりになっています。

ただ、Rails講座だけはさすがに難易度が高かったです。。。これは、Progateさんの講座の作り云々ではなく、Webフレームワークという概念が初学者にとって「始めまして」になるので、多少仕方がない部分ではあると思います。

1周目で全体像の把握、2週目以降で詳細理解に努める、というスタンスでよいかと思います。

3.2 Ruby on Railsチュートリアル

皆大好き(?) Rails チュートリアル。

URL: https://railstutorial.jp/

色々賛否ある教材ですが、無料かつ、ここまで体系的に「RailsのWebアプリ開発」を学べる教材は他にないと思います。

本教材の謳っているところでもありますが、「単にRuby, Railsの学習に終始せず、Webアプリ開発の全体像を俯瞰する」ものですので、本教材での知識は、他言語・他フレームワークで開発をする場合でも大いに活きると思います。

確かに、当教材に対する否定的な意見はいくつか見受けられ、

テストフレームワークとして、国内企業でデファクトスタンダードになっているRspecではなく、Railsに標準搭載されているminitestを使用している

採用技術が古くなってきてしまっている

という点がよく指摘されています。

ただ、前者については、株式会社YassLab代表のコチラのYoutube動画の動画でも説明がある通り、「かつて(第２版まで)は Rspec を Rails チュートリアルでも採用していたが、Rspec 自体の学習コストが高いこともあり、それによる脱落者を多く出していた」という背景を受けてのものになります。

また後者については、例えば現在の Rails企業の多くは、Rails単体のアプリケーション(フロントはjQery/bootstrap)ではなく、APIとしてRailsを利用し、フロントはJSフレームワーク(Vue.jsやReact.js)を使うのが一般的になってきています。しかし、Rails初学者が、いきなりAPI開発から始めるのは、理解の階段を飛ばしすぎている、というのも事実でしょう(これについては、同者のコチラのYoutube動画も参考になるかもしれません)

つまり、Rails チュートリアルは「Railsを初めて触る人がなるべく挫折しにくい難易度設定を目指す」ということを念頭に置いた教材であり、最前線の現場で使用されているような本格的なRailsの習得の橋渡しをするようは役割である、と考えることができるかと思います。逆に、これ以上現場に近づけた本格的な内容にしてしまうと、それこそ多くの初学者が挫折してしまうと思います。

したがって、Rails初学者は、今この時代であっても、自信を持って当教材取り組んでよいと思います。少なくとも自分は、この後にも続くRails学習において、ベースとなるような知識をつけることができた、と感じています。

ただ、いくら難易度を落としているとはいってもRails初学者に取ってはかなり難しく、かつ量も膨大であるのは事実です。そのため、Railsチュートリアル完走を一つのマイルストーンとして設定し、内容につまづいたら「ひたすらググる」あるいは「適宜Progateに戻る」という進め方が効率的かと思います。

私も、一度はあまりの量と難易度に挫折してしまったのですが、社会人としてすでに働いており、ある程度お金に余裕があったので、動画版を購入して最後までやり切りました。個人的には、人が解説してくれている形式の方が理解がスムーズで、モチベーションの維持もしやすかったで、お金に余裕のある方にはオススメです。

Railsチュートリアルで身につく知識を整理すると、

バックエンド: Rails(シングルアプリケーション)

フロントエンド: jQuey+bootstrap (Railsの一部として内包)

テスト: minitest

開発環境: AWS cloud9

デプロイ: Heroku

全くの初心者からWebアプリとして求められる一通りの機能を実装し、本番環境へデプロイするところまでできるのは、やはり教材として素晴らしいと思います。

しかし先ほども述べた通り、当教材はあくまでも橋渡しの位置付けです。未経験からの転職という自分自身の立場を鑑みると、Web系企業への転職用PF作成の準備としては、技術面でまだ心許ない、と考えました。

改めて複数企業の採用ページから実際に企業で使用されている技術を確認し、上記の学習知識と比較して整理をすると、

フロントは、Vue.jsやReact.jsといったJavaScriptフレームワークを使用するのが一般的。それに伴い、Railsは単独アプリとしてではなく、APIモードで開発する

テストフレームワークは、minitestではなく、Rspecがデファクトスタンダード

開発環境はPCローカルに構築する(Vagrantで仮想マシンを構築するか、Dockerでコンテナ化するか)

アプリケーションのデプロイは、小規模であれば Heroku を使うこともあるが、企業が提供するような中・大規模なアプリケーションであれば、AWSやGCPなどをよく用いられる

次に習得すべきは、ここの技術領域であることが分かりました(個人的な話ですが、この辺りの時期からエンジニア採用ページに書かれている各技術がスタックが、どういった内容であるかが理解できるようになってきており、成長を実感していました)。

Railsチュートリアルを完走した方は、完走者向けのロードマップ紹介ページもありますので、まずはここを見てみるものよいかと思います。しかし私は、洗い出した上記項目をより体系的に学ぶことができるものがないかと考え、自分なりに色々と教材を探してみた結果、以下のサービスに辿りつきました。

3.3 Take off Rails

URL: https://freelance.cat-algorithm.com/lp/take-off-rails

『あなたを「初心者エンジニア」から「現場で活躍できるエンジニア」まで引き上げます。』というスローガンを掲げた教材とメンターがセットになったサービスで、Rails チュートリアルと実際の企業の間の穴埋めを狙った内容になっています。

基本的にはすでに作成された教材に則っとりながら自分のペースでアプリを開発していくのですが、都度 Slack でメンターさんに質問を投げることができるというのが大きな特徴です。。

最終的な教材のゴールとしてはQiitaのクローンサイトを開発することになります。これの技術スタックは下記の通りです。

バックエンド: Rails APIモード

フロントエンド: Vue.js (ソースコードは作成済みのものを使用。あくまで Rails との繋ぎ込みまでを扱う)

テスト: Rspec(+Factory_bot)

開発環境: ローカル + DB(MySQL) は Docker コンテナを利用

アプリのデプロイ: Heroku

その他: CircleCI による rspec, rubocop の自動化

※ 私の当サイト用のリポジトリ： https://github.com/ddpmntcpbr/qiita_clone

Railsチュートリアル時点での技術スタックと比べると、かなり実務に近い技術が盛り込まれていることが分かるかと思います。

こちら、決して安い金額ではないサービスだと思います(スクール等に比べれば全然安いですが)。ただ、当時欲しいと思っていた知識が一気に身に着けられると考えて、購入を決意しました。

結果、良い買い物だったと思います。自分が学びたい内容がきれいに体系化されていたこともそうですが、何より、教材内容についてメンターさんへ質問ができるのも有意義だと感じました。遅くとも24時間以内にはレスポンスが返ってくるのもありがたく、「料金分を回収してやるぞ！」という気持ちで、たくさん質問させてもらいました笑

本教材では、上記技術の学習だけでなく、

Git commit の適切な粒度や、コミットメッセージの書き方

Github での PR の出し方や、コードレビューの流れ

Slack でのやり取り(意図が伝わりやすい質問の仕方など)

といった、「独学ではなかなか身につかない」けど「チーム開発では必須になる」ような周辺知識について学べた点も、非常に有用だったと思います。Railsチュートリアルの内容がおおよそ理解できていれば前提知識としては十分な難易度で、大きく挫折をすることがなかった点もプラスです。

さて、ここまでで、Railsに関しては、比較的モダンな開発手法に触れることができました。

しかし、当教材ではあくまでも Rails の開発に的を絞ったものであり、フロントエンドは既存のソースコードを流用する形での学習でした。この教材の内容を自身の転職用PFに組み込むためには、フロントエンド側についても自身で開発する知識が必要と考えました。

フロントエンドフレームワークの選定について、第２章でもお伝えしたとおり、「Reactの方がなんとなくよさそうかなー」と考えていたところ、次の教材を見つけたことをきっかけに、正式に React の学習を始めることにしました。

3.4 【とらゼミ】トラハックのエンジニア学習講座

現役の React エンジニアであるトラハックさん ( @torahack_ )が、Youtube上で公開している講座で、Reactについて基礎の基礎から学ぶことができます。

動画チャンネルURL: https://www.youtube.com/user/1492tiger

こちらの教材の特長は、

Reactの基礎の基礎から体系的に学べる( Progate の JavaScript 講座完了が受講目安)

動画によるハンズオン形式

教材範囲にモダンなフロントエンドの開発手法を含む( Redux 等)

動画のほぼ全てがYoutube上でなぜか無料公開されている

特に最後については完全にバグとしか思えない点で、Udemyなどで有料販売されていても動画講座と比べても遜色ないクオリティだと思います。

動画教材にありがちな「準備した原稿丸読み」のような堅い口調ではなく、フランクな若手予備校教師の授業(?)のような語り口のため、硬い喋りが苦手な人にもお勧めできます。私は復習のために、一度見た動画を耳だけで聞き返したりして、記憶の定着を図りました。

講座はいくつかのシリーズに分かれており、私が視聴をしたのは、

1.『日本一わかりやすいReact入門』シリーズ
2. 『日本一わかりやすいReact入門【実践編】』シリーズ
3. 『日本一わかりやすいReact-Redux入門』シリーズ

の3シリーズです。

最終的な成果物の技術スタックは、

create-react-app

Redux & redux-thunk

Material-UI

Firebase： Google が提供する mBaaS。バックエンド＋インフラを手軽にセットアップできる

です。

※ 私のGithubリポジトリ: https://github.com/ddpmntcpbr/react-ec-app

こちらの動画については、学習備忘録記事をQiitaに投稿しております。よろしければこちらもご参考下さい。

参考ページ: 『日本一わかりやすいReact入門【実践編】#1~5 学習備忘録』

本学習講座を全て受講するためには、有料コミュニティ『とらゼミ』への加入が必要になりますが、筆者は無料公開範囲の動画で必要な知識は十分に身に付いたと感じたため、加入はしておりません。（代わりの記事として書くことで、宣伝として少しでもお役に立てればと思っています笑）

さて、ここまででフロント側も自力で開発ができる基礎が身に付きました。これくらいの時期に並行してアプリのコンセプトが決定していましたので、いよいよポートフォリオ作成に取り掛かり始めました。

しかし、開発を始めるといくつも壁が出てきます。基本的にはググりながらの解決をしていきましたが、どうしても解決できないエラーにもぶち当たりました。特に、

ReactとRailsの繋ぎ合わせ

AWSでのアプリの公開方法

その他インフラ知識全般

あたりが、個人的な難所でした。その過程で頼らせてもらったのが、次のメンターサービスです。

3.5 TechTrain

有名企業のエンジニアから実務を学べるオンラインコミュニティ です。

URL: https://techbowl.co.jp/techtrain

特長を列挙すると、

現役エンジニアであるメンターさんと、1 on 1でのオンライン面談が可能

メンターの方々の技術領域は多種多様

全てのメンターと面談が可能で、技術トピックに応じて切り替えることが可能

面談はこちらからのタイミングで入れることができる

なぜか全て無料で利用できる

はっきり言います。これだけのことができて完全無料なのは完全にバグです。これからエンジニア就職を目指しているU30の学生・社会人は、全員登録した方がいいレベルです

TechTrain の中ではいくつかの Mission が設けられており、それをメンターと一緒に取り組んでいくことで知識を習得していく、ということが可能です。 Mission は実際のIT企業とのコラボで作成されており、中には「Missionをクリアできた人は一次面接をスキップできる」のような特典もついていたりします。

ただ私は Misson には取り組まず、あくまでの個人開発のサポートとして利用させてもらっていました。基本的には自身の既存知識とググり力でPF作成を進めつつ、どうしても解決できない課題が出てきたときにピンポイントで面談予約を入れる、というイメージで、個々人の利用したい形式/ペースで利用できる点も大変ありがたかったです。

異なる技術領域を持ったエンジニアの方々全員と面談をするが可能なため、Rails, React, AWSそれぞれで、別のメンターの方に質問をさせてもらっていました。

特に自力での解決が難しかったのがAWS周りの本番環境構築で、本サービス無しでは乗り越えられなかったと思います。

AWSのことをAWS現役社員に無料で聞けるサービスと表現すれば、このサービスのやばさが伝わるかと思います。

最終的には、自身のググり力 + TechTrain で都度メンターを利用、を繰り返すことで、無事アプリを完成させることができました!

3.6 番外編

上記以外で役に立ったものについて、ざっくばらんに紹介します。

Udemy 『Git：はじめてのGitとGitHub』

無料で Git の基礎を学べる講座です。「Gitよう分からん！」って人は、まずこれから触れてみましょう

 『キタミ式イラストIT塾基本情報技術者』

基本情報処理の定番本です。コンピューターサイエンス領域の基礎知識が体系的に学べます。イラストが豊富であり、文章表現も柔らかいので初心者にも優しいです。資格自体の取る/取らないに関わらず一読をオススメします。

『米国AI開発者がゼロから教えるDocker講座』

Dockerについて一から学べる動画教材です。作者様はデータサイエンス領域の方ですが、Webアプリ開発を目的とした人であっても問題ありません（実際に、講座後半では、docker-composeを利用したRailsコンテナの構築まで扱っています）

非常にボリューミーな内容にも関わらず、Udemy講座の中ではかなり良心的な価格設定です。

『【AWS 入門】EC2とDockerでHello Worldしよう』

AWSについて何にも分からない状態から、「nginxだけのシンプルなコンテナアプリを動かす」ところまで、ハンズオン形式で学習ができます。

AWSのとっつきにくさは、「①インフラの概念が分からない」「②専門用語が分からない」に集約されると思います。まずは手を動かしながら、AWSでアプリをデプロイ流れを全体像で掴むことができます。

3.7 アプリの改善点

一通りアプリを完成させてみて、初めて見えてくる改善点が多くありましたので、合わせて列挙します。

AWSサーバー代高すぎ！！！

スケーラビリティの高い中・大規模向けインフラ構成になっているため、サーバー代がめっちゃ高い笑

長く公開するためには、どこかのタイミングで無料サーバーへ移管する必要があるかなと思います。Heroku の無料枠で上手にやりくりできれば、解決できるかもしれないです。

フロントエンドは Next.js + Typescriptで実装したい

Next.js はレンダリングのタイミングを制御できるので、OGP情報の保持が簡単に実現できます。

また、それ以外でも、

ルーティング設定が簡単

パフォーマンスをよくするような機能も豊富

Typescriptの導入が用意

というメリットもあり、とても気になっているフレームワークです。次、全く同じアプリを開発するとするのであれば、絶対に採用したい技術です。

デザインがあやしい気がする・・・？

アプリを開発して気づいたのは、アプリにおけるデザインの重要です。

これを思った理由は単純で、開発途中で「なんか自分のアプリ、イケてなくない？」と感じたからです笑

Webアプリにおけるデザインは、単なるお洒落さに関するものだけでは決してありません。デザインは、ユーザーにとって必要な情報を適切に配置することであり、ユーザーの価値提供のための最前線領域です。

ユーザー側から価値提供の流れ(バリューチェーンと表現するのでしょうか)をざっっっくり並べると、

ユーザー -> UI/UXデザイン -> フロントエンド -> バックエンド -> インフラ

のようになっていると思っています。「エンジニアになろう！」と意気込んで後ろ3つについてはそこそこ勉強してきましたが、デザイン領域については開発初期は完全素人の状態で、途中までは勘でやっていました。。。

一応、付け焼き刃程度ではありますが、デザインの名著である『ノンデザイナーズ・デザインブック』に目を通し、途中からは意識できる範囲ではデザインのことを意識して、フロントを実装しました。

うまく取り込めているかは分かりませんが、少なくとも「デザインはセンスではなく論理」であることが学べただけでも、よい勉強になりました。こちらの書籍も、転職用PF作成者にオススメしておきます。

4. さいごに

以上、大変長い記事でしたが、最後まで読んでいただきありがとうございました。タイトルでは「学習ロードマップ」と銘打っておきながら、私自身の思考プロセスや価値観についても多く書かせてもらいました。

「エンジニアになりたい！」と思い立ってから、学習自体はほぼ一人で淡々と進めてきました。しかし、ほぼ独学でここまで学習を進めることができたのは、多くの先輩エンジニアの方々が様々な情報をインターネットに投稿し、それをオープンに取得できる環境にあったからだと思っております。

それであれば、次は自分自身も。他の駆け出しエンジニアの方々の助けになるような情報を発信できれば、と思い、この記事を書くこととしました。

もし、参考になったという方がいましたら、せひLGTM、ストック、twitterでのシェアお願いします！

また、私自身もtwitterをやっておりますので、気軽にフォローしてもらえるとうれしいです(^^)

よろしくお願いします！

Twitter: https://twitter.com/ddpmntcpbr
Github: https://github.com/ddpmntcpbr/rails_react_docker

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T14:13:23+09:00

【未経験PF/Rails/React/AWS/Docker/CircleCI】独学＋メンターでここまで出来た！Web知識ゼロからモダンな技術アプリ開発までに利用した5つのサービス

0. はじめに

こんにちは！辻野(@ddpmtcpbr)と申します。

当記事は、「Webエンジニアへのキャリアチェンジを目指している開発未経験者が、モダンな技術を備えたアプリを開発するまでの学習過程」についてまとめたものです。

現在筆者は非IT系企業の社員として働いており、Web開発エンジニアとしての実務経験はありません。

そんな筆者がWebエンジニアとしてのキャリアチェンジをするためのポートフォリオとして、本アプリを開発しました。

学習開始から現時点までにおいて、プログラミングスクール等には通っておらず、学習はほぼ全て独学&一部メンターサービス利用の布陣で進めてきました。

独学中心でアプリ開発に挑戦したい、ポートフォリオを作成してWebエンジニアへのキャリアチェンジを進めていきたい、と考えている方々にとって、参考になればと思います。

最初に、今回私が開発したアプリの概要を紹介します。

アプリ名：積読解消アプリ「Yomukatsu!」

「あなたの積読解消をサポートします」をスローガンに掲げたSPA風Webアプリです(”風”の詳細は後述)。

読書メンタルマップという手法を用いて、ユーザーの書籍完読に向けたモチベーション維持をサポートします。

Web URL: https://yomukatsu.com/

【3分動画】Yomukatsu 字幕解説

アプリの使い方を3分でまとめています。

使用技術

Backend: Rails ( API mode / Rspec / rubocop) + Nginx ( upstream puma-socket )

Frontend: React ( create-react-app / Redux / Material-UI / eslint&prettier)

Infra: AWS ( ECS Fargate/ ECR / RDS / ALB / Route53 ), Netlify, Docker&docker-compose, CircleCI

各項目の詳細は後述しています。

インフラ構成

モダンな技術を採用したWeb系企業が提供している、中・大規模なアプリケーションを想定したインフラ構成にしています（そのため、個人開発アプリとしてみるとちょっと仰々しいかもです(;’∀’)）

詳細は後述しています。

機能一覧

ユーザー利用機能

Twitterアカウントを利用したユーザー登録(OAuthによるSNS認証)

ゲストログイン機能

Google Books APIを用いた書籍検索機能

Google Books、Amazon、楽天ブックスへのリンクボタン配置

Twitterシェア機能

ハッシュタグ「#yomukatsu」付きTweet

Twitter card 表示

Twitter card用にリサイズした書籍画像をAWS S3へ保存・管理

Redux による state 管理を活用したローディング画面

Slack Incomming Webhookを利用したお問い合わせ機能

Route53 による独自ドメイン + SSL化

非ユーザー利用機能

Netlify の Pre-reidering 機能活用による動的なOGP情報の保持（ Twitter card 表示用）

Docker による開発環境の完全コンテナ化

CircleCI による自動 CI/CD パイプライン構築

CI: Rspec, rubocop, eslint&prettier

CD: AWS ECR

その他セキュリティ対策(XXS, CSPF等)

まず触ってみてもらうのが一番良いかと思います！今回はフロントエンドに React を採用しているため、メニューモーダルの開閉や通知バー表示など、アニメーション的な表現も実装できているのが伝わるかと思います。

ゲストユーザー機能もありますので、気軽に利用してみてほしいです！レスポンシブにも対応しています。(推奨ブラウザはChrome、Safariになります）

アプリURL: https://yomukatsu.com/

※現在α版としてのリリースのため、配信内容が予告無く変更される可能性がございます

あわせて、 Githubも公開していますので、よかったら参考にしてください。

Github URL: https://github.com/ddpmntcpbr/rails_react_docker

この記事について

当記事は3章構成になっております。

まず、「1.自己紹介」で、簡単に自己紹介をさせていただきます。

次に、「2.開発アプリ解説」で、今回の開発アプリ開発について、コンセプト決定の流れから、実装機能/技術スタックについて詳しく紹介します。「転職用PF作りたいけど、どんなアプリを作ればいいか分からない」という方にとって、参考になることがあれば幸いです。

最後に、「3. 学習ロードマップ」で、Web知識ゼロだった筆者が、当アプリの開発にまでに利用した5つの教材およびサービスについて、時系列に沿って紹介したいと思います。特に独学では、「まず何を学べば良いのか」「どんな教材を選べば良いのか」というところから自身で考える必要があります。そういった方々にとって参考になり得る情報と思います。

1. 自己紹介

1.1 筆者スペック

20代後半男

工学部機械系修士卒 → 非IT系日系製造業技術開発職(現職)

大学から現職において、データ分析ツールとしてプログラミングを経験(matlab / python)

Webエンジニアへのキャリアチェンジを目指し、社会人になってから独学を開始

大学入学以降、授業や研究データの分析ツールとしてプログラミングに触れる機会はありました。もともと自動化や効率化に興味があったことからプログラミングにだんだんとのめり込み、研究室ではプログラミングに多く触れられそうな研究テーマ(データ分析系)を選びました。

したがって、「プログラミング自体が完全に未経験」というわけではありませんでした。しかし、いわゆる”Web系”の知識は社会人以降の独学を開始するまではゼロ、という状態で、最初は HTML すら知らないところからのスタートでした(￣▽￣;)。そのため当記事では「Web知識ゼロ」という表現をしています。

キャリアチェンジ志望の理由は、ざっくりと言えば、

1. もっとプログラミングがしたい
2. モノづくりで誰かの役に立ちたい
3. 非効率・非生産的な仕事を無くしたい

ここについては当記事の趣旨ではないので、詳細については省略します。

2. 開発アプリ解説

2.1 コンセプト方針

転職用PFアプリのコンセプトを決めるにあたり、満たすべき用件としては、下記3点を考えました。

(a) 実際の企業が採用しているようなモダンな技術を盛り込む
(b) 具体的な解決課題を明確にする
(c) サービスの利用が個人で完結する

(a) 実際の企業が採用しているようなモダンな技術を採用する

未経験からエンジニア転職において、高品質なポートフォリオは必須と考えました。

「モダンな技術をポートフォリオに組み込むことで、技術力の高さをアピールする」というのが基本的な考え方になるとは思いますが、個人的な解釈としては、ポートフォリオで証明すべきは「技術力」ではなく「自走力」だと考えています。

ぶっちゃけた話、実際の現場を経験したエンジニアと比べれば、未経験者間での能力差というものはどんぐりの背比べのようなものだと思います。多くの企業が「実務経験1年以上」をエンジニアの採用項目にあげていることからも、実務経験というのはそれだけ重い価値があり、未経験者とは大きな隔たりがあるのだと思います。

したがって、ポートフォリオの技術レベルの高さそのものはあまり重要ではなく、そこに到達するまでの過程の方が大事であり、「自走力＝必要な情報は自らキャッチアップして吸収する能力」があることを示す方が、企業人事側としては採用しやすいのではないか？と考えました。

「スクールの制作アプリをそのまま提出する未経験者が足切りされてしまう」という話は多く聞きますが、これはそのアプリの技術力が低いからではなく、そのアプリから当人の「自走力」が主張できないから、だと私は考えています。私が独学ベースにこだわったのは、単純にお金の問題だけではなく、独学ベースでアプリを開発することができれば、自然とそれが「自走力の証明」につながると考えたからです。

今回のアプリにおいては、「独学:メンター=8:2」くらいの割合で、上記技術を採用できるラインまで行くことができています。「メンター利用は独学からは外れるのでは？」という指摘もあるかもしれませんが、

プログラミングでは、個人ではどうにもならないようなエラーに遭遇してしまうことが多々ある

実際に企業に入ってからは、先輩エンジニアの方々に分からないことを質問しながら業務を進めることになるため、「質問力」も重要な能力である

完全独学オンリーだと、誤った癖が身についてしまっているリスクが高くなる

といった観点から、独学者が適宜メンターサービスを利用することは、かえって採用人事側にとって安心感を与える材料になるのでは、と考えたので、自信を持って「メンターサービスを使いました」と主張しています。

※ 具体的なモダンな技術リスト

Rails API + JSフレームワーク(React.js)の構成

Dockerで実行環境を完全コンテナ化

Herokuではなく、AWS でアプリをデプロイ(ECS Fargate & ECR)

Circle CIによるCI/CDパイプラインの構築

(b) 具体的な解決課題を明確にする

さて、前章とは一見真逆のことを言いますが、アプリ開発において、モダンな技術を採用することそのものには本来何の価値もない、と考えています。

なぜなら、アプリの目的はあくまでも「ユーザーにとって価値を提供できるか」であり、技術はそれを実現するための手段でしかないはずだからです。(保守・運用面でのメリットも考えられますが、保守・運用の最終目的もユーザーへの価値提供であることから、この点も包含した解釈になります)

これは、技術というものを下に見ているというわけでは決してありません。むしろ「新しい技術をどんどん使ってみたい！」という技術に対する好奇心、探究心は人一倍強い自負があります。現職はIT系ではありませんが、技術開発職という立場で業務に取り組んでおり、知的好奇心を満たせるという意味では、今の仕事に面白みを感じています。

しかしながら、かつては行き過ぎた技術先行思想によって「手段の目的化」が発生し、「最新技術を駆使した誰にとっても役に立たない技術」を開発してしまったという苦い過去の経験があったりもします。結果として「やっぱり技術は人の役に立ってなんぼ」というのが、約3年間技術職として働いてきて培った、技術者としての小さな矜持だったりします(この辺の話は直接お会いした方にはお話できるかと思います)

転職用PFであれば、技術ありきな考え方になることはある程度は仕方がないことでしょう。しかし「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」くらいのことは転職用PF作成においても考えていいんじゃないかな？と思いました。あるいは、もう少し目線を下げて「自分が欲しいものを作ろう」という程度でも十分でしょう。大事なのは、まず課題があり、それを解決する手段として技術があるという順番だと思いました。

もちろん今回の開発アプリは転職用PFが趣旨である以上、中には「技術力を証明したいから」という理由で選定した技術もあり、全てに対して課題が明確だったわけではありません。また、初心者の個人開発アプリがいきなりバズることは現実的には厳しいとは思います。しかし、そこを目指す姿勢があるかというのは、エンジニアとして本格的にキャリアを進めていく上では、長期的には大きな差異になると考えています。

また、

課題が明確な方が採用した技術や実装した機能の根拠も明確にできるため、開発の方針を立てやすい

自身がユーザー目線に立てることで、改善点を見つけやすい

純粋にモチベーションを維持しやすい

といった点でもメリットもあると感じましたので、この方針は間違っていなかったと思います。

(c) サービスの利用が個人で完結する

「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」を、もう一歩深く考えた方針です。

例えば Rails を対象として考えたとき、一般的な転職用PFとしては、TwitterライクなSNS系アプリや、メルカリライクなEC系アプリが多いかと思います。

理由は、ユーザー認証、CRUD操作、DB間のリレーションなど、基本的なサーバーサイド技術を一通り抑えられるものであるから、だと思います。「Railsの一般的な知識を持っていることを証明する」手段と考えれば、妥当な方針でしょう。

しかしながら、未経験者が転職用に開発した上記アプリが実際にユーザーに継続して使われるということは、まず無いでしょう。SNS系アプリは「ユーザー数が多ければ多いほどサービスとして質が高まる」性質があるため、アプリとして軌道に載せること自体が非常に難しいです。EC系アプリは BtoC であれば出品企業がいないとサービスが成り立たない、CtoCであればより SNS として要素が強まる & いよいよメルカリで十分、という壁があります。

これらアプリの難しさは、ユーザーどうしがつながることを前提としている点にあります。裏を返せば「個人で完結するアプリであれば、活路はある」とも言えると考え、この方針でコンセプトを詰めていくことにしました。

2.2 コンセプト内容

上記3点を念頭に置きながら、自分自身の生活の中で"課題"を探し、最終的にたどり着いたものが「読書メンタルマップ術の電子化」というコンセプトでした。

そもそも皆様は、読書メンタルマップ術というものをご存知でしょうか？

読書メンタルマップ術とは、ハーバード大学の先生が提唱している積読解消術です。読破したい書籍に対して、

1. 完読したい本について、それを読む“理由”や“目的”を3つ、紙に書きだす
2. 飽きてきたら、それを見返す

を繰り返すことで、完読までモチベーションを維持するというシンプルな読書手法です。

積読というものは、だいたい「最初は読む気があったけど、次第に読む気がなくなってしまった」書籍です。この「最初の読む気」を事前に明文化・保存しておくことで、いつでも最初の頃に新鮮な気持ちを取り戻せるようにしておこう、というイメージになります。

自分自身、実際に活用している技術ではあるのですが、少し困ったことがあります。それは、電子書籍との相性が悪いことです。

通常であれば紙とペンを用いるものですが、例えば出先でスマホやタブレットで電子書籍を読んでいるような状況では、必ずしもこれらの道具があるとは限りません。特に私は、外に出る時はあまりものを多く持ちたく無い性分なので、外ではスマホと財布くらいしか持っていないことが多いです。

仮に持っていたとしても、例えば電車の中で紙とペンを出して色々と書き始めるのは、少し億劫だったりします。

「これを全部ペーパーレスで完結できるようなアプリがあったら便利だな」と思ったのが、このコンセプトを思いついたきっかけになっています。

もちろん、これだけであればスマホのメモ帳だけでもできてしまうものですが、このアプリには、

Google Books APIを活用した書籍検索・保存機能

メンタルマップ作成のヒント機能

Google Books, Amazon, 楽天ブックスへのリンクボタン配置(特に書籍レビューはメンタルマップ作成の大きなヒントになる)

Twitterでの読書仲間への気軽なシェア機能

といった機能が備わっており、より読書メンタルマップ術を使用しやすい環境を整えています。

先ほどの「2. 具体的な解決課題を明確にする」に照らし合わせて考えると、このアプリの解決課題は、ユーザーの積読を解消すること、もっと言えば、読書メンタルマップ術をペーパーレスで実行できるすることで電子書籍で読書するユーザーにとっても扱いやすくすること、になります。

また、「3. サービスの利用が個人で完結する」も満たしています。当アプリには、ユーザー同士がつながる機能は一切実装されていません。

代わりとして、Twitterとの連携にはかなり重きを置いて実装機能を決めました。具体的には、

Twitterアカウントを利用したユーザー登録

ワンタップでハッシュタグ付きツイート

充実した Twitter カード表示

を機能として実装しています。原則的には個人でサービスが完結しつつも、ユーザーどうしの繋がりはTwitter内の既存のネットワークに乗っかる、ことを狙ったコンセプトになっています。

2.3 技術スタック

再度、インフラ構成を載せます。

この内容について、ひとつひとつ解説します。

Back-end

Rails API + Nginx の組み合わせにしています。

サーバーサイドフレームワークとしては他にも Laravel, Django, Node.js などもあります。恐らく大体のことは、どれを選んでも実装・実現できる、と思うのですが、その中で今回 Rails を選んだ理由は、

採用している企業数が多い

日本語の教材が豊富なため学習のハードルが低い

国内コミュニティが発達しているため、インターネット上での日本語ドキュメントが豊富

最初の学習言語として Rails を選択する初学者の方は多くいるかと思います。その一方で、「Railsはオワコン」という説が各所で言われていることについて、不安に感じる初学者の方もいると思います。

この点に関して、あくまで個人的な見解を述べますと、初学者であった自分が、少なくとも最初に学ぶ言語/FW として Rails は間違いではなかった、と考えています。

正直、初学者である私には、「なぜ Rails がオワコンであるのか」について技術ベースで語ることはできません。しかし、

現時点で Rails を採用している企業の絶対数は多く存在すること

日本国内において、Rails に替わるサーバーサイドのデファクトスタンダードな技術が、まだ定まっていないこと

は事実と言ってよいかと思います。

もしかしたら、長期的に見れば日本国内でも Rails を採用する企業が減っていく流れにはあるのかもしれません。しかし、微分値と絶対値はセットで捉えないと判断を誤ることになります。初心者が目指すべきは「今すぐに仕事を得られる技術を身に着けること」であり「将来必要になってくる技術」ではない、自分が今学ぶべきはやはり Rails である、と判断をしました。

また、オワコンというのは裏を返せば、技術的に枯れていて、初心者にとっては学びやすい言語/FWである、とも言えます。

特に日本国内での(過去含めた)使用者が多いため、日本語のドキュメントが多く存在します。事実、Rails開発で遭遇するエラーは、Google検索すれば何かしらの日本語記事がヒットします。

最先端の技術は過去の技術の欠点を補う要素を持って生まれてきているのは事実ですが、検索しても欲しい情報が見つからなかったり、あったとしても英語ドキュメントだけだったりします。私自身は、このアプリの開発を通じてWebフレームワークに基本的な概念が身についてきているため英語でも大丈夫になってきましたが、ベースラインすら乏しい状態の初学者がいきなり英語のドキュメントを読み解いていくのは、二重にしんどいです。

以上が、私が最初の言語/FWとして Rails を選んだ根拠になります。

主要gem

devise_token_auth： APIモードでの devise。トークン認証を簡単に実装

twitter_omniauth：Twitter認証を簡単に実装

active_model_serializer： Rails APIからのレスポンスJSONを制御

imageMagic: 画像のリサイズを実行。特に、Twitter card用に書籍画像をリサイズする際に使用

aws-fog/carrierwave: リサイズした書籍画像を AWS S3 に保存

rspec：デファクトスタンダードになっているRubyテスト用フレームワーク

rubocop： Rubyの静的コード解析

TwitterアカウントでのOAuth認証は、過去の実装例が少なく、非常に苦労したところでもありました。しかし、「Twitterとの連携を重視」という今回のコンセプト上では絶対に欲しい機能と考え、頑張って実装しました。

AWS S3については元々採用予定はなかった(Google Books APIの画像リンクをそのまま引っ張ってくる予定だった)のですが、Twitter card で書籍画像を表示させる時にどうしても画像サイズを適切に制御する必要が出てきたので、imageMagic と合わせて Rails で画像リサイズ & S3保存、を実装することにしました。

Front-end

今回フロントエンドとしては、JSフレームワークであるReact.jsを採用しました(細かいこと言えば React はフレームワークではなくライブラリですが、ここではフレームワークとして扱います)。モダンな技術採用を謳う以上、Rails + jQuery/bootstrap の構成では心許ないと考えました。

JSフレームワークとしては、国内企業での採用状況から考えるに、React.jsかVue.jsか、の二択になると思います。その中でもReact.jsを選んだ理由は、

自分が調べた範囲では、バックエンドに Rails を採用している企業群のうち、フロントに React を採用している企業の割合が高かった

Vue.js よりも規約が厳格であり、初学者の自分であっても自然と可読性の高いコードを書くことができそう

たまたま、React を効率的に学べる良い教材を見つけた

特に最後については、第３章で後述しています。

アプリ開発を通じて React.js が割と気に入ってきたので良い選択だったとは思いますが、この点に関してはどちらを選んでも間違いではなかったかな、とは思います。

主要ライブラリ等

create-react-app: Facebookが提供するオープンソースのReact開発パッケージ

Redux: Stateの一元管理するフレームワーク。Redux関連ファイルは、reducksパターン則って管理

Redux-thunk: Redux state の非同期処理を制御

react-helmet: 動的なmetaタグの挿入によるOGP情報の保持(Twitter card用)

react-share: Twitter含めたSNSシェア用ボタンを簡単に配置

Material-UI ： Google が提供する UI コンポーネントライブラリ。簡単におしゃれな UI コンポーネントをアプリ内に配置できる

eslint & prettier: javascriptに対する静的コード解析。eslint は create-react-appに標準搭載されているものをベースに少しプラグインを追加 & prettier はイチから導入

今回はユーザーの利用シーンを考えると、Web上でもネイティブアプリのようにサクサク動く、JSリッチなアプリケーションにしたいと考えました。この点からも、jQuery+bootstrap ではなく React.js を採用してよかったと思います。

React の実装には、特にMaterial-UIが強力で、開閉モーダルや通知バー表示などのアニメーション演出や、ページ全体のレスポンシブ対応などがかなり簡単に実装できました。このライブラリを使えたというだけでも、React を採用した価値があったと思えるほどでした。

Infra

Docker/docker-compose

開発環境は、全てDockerコンテナ内で完結させています。docker-compose.ymlのサービス構成としては、

db: MySQL

api: Rails

web: Nginx

front: Node.js (React)

としています。

後述しますが、AWS ECS(Fargate)へのコンテナデプロイを利用することで、開発環境と本番環境の差異を小さくすることができています。

AWS(Amazon Web Service)

バックエンド( Rails + Nginx )のデプロイに使用。Railsチュートリアルなどではアプリの本番環境へのデプロイにはHerokuを用いることが一般的ですが「モダンな技術を採用したい」という観点から、AWSに挑戦しました。

稼働させるまでめちゃくちゃ苦労しました。ここを完全独学で完結させるのは相当しんどいと思います。第３章で触れていますが、AWSの学習については、メンターさんをかなり頼らせてもらいました。

※ 利用サービス

ECS (Fargate): コンテナ向けサーバーレスコンピューティングエンジン。この中に Rails と Nginx の Docker イメージを入れて稼働させる

ECR: Rails と Nginx の Docker イメージを保存しておくリポジトリ

RDS (MySQL): AWS が用意しているスケーラブルなデータベースエンジン

ALB: 負荷分散を担うロードバランシングサービス

Route53: サイトの独自ドメイン化に使用

ACM: サイトの https 化に使用

S3: 静的ホスティングサービス。書籍画像も保存・管理に使用

Netlify

フロントエンド(create-react-app)のホスティングで利用。

最初はバックエンドに合わせてフロントも AWS ( Amplify Console ) でホスティングしていたのですが、create-react-appはSPAとしてのアプリ開発となることから、metaタグ無いにOGP情報を保持できない = Twitterでページをシェアした時のカード表示を動的に制御できない、という問題が出てきました。

おそらくは AWS でも解決する手段はあると思うのですが、今回は Netlify の Pre-rendering機能を使うことで解決することにしました。この機能を使うことで、 create-react-app であっても、サーバー側で javascript をレンダリングしてからブラウザが解釈できるようになります（あと単純に、無料で利用できるのもメリット）

この問題にあたってから、最近ホットな React フレームワークの Next.js の有り難みが自然と分かるようになってきた( Next.js は SPA/SSG/SSRを選択可能 )のですが、今回はすでに開発を始めていたこともあり、create-react-app + Netlify の構成で最後まで開発しました。

CircleCI

国内ではデファクトスタンダードとされている、Saas型のCI/CDサービスです。今回CircleCIで自動化した処理は、

Rspec

rubocop

eslint&prettier

AWS ECR への Image push

AWS ECS のタスク&サービスの更新

Netlifyにはもともと自動デプロイ機能がついていることから、CircleCIを導入することで、Github上の master ブランチに merge しただけで、本番環境への再デプロイが完了する、という状態に持っていくことができました。

一度ありがたみが分かると、もう手放せないですね( ´ ▽ ` )

3. 学習ロードマップ

さて、いよいよ本題です。ここまでで開発したアプリについて解説をしてきましたが、ここからは、このアプリ開発に至るまでの学習過程をたどっていきます。

第1章でもお伝えした通り、筆者はプログラミング経験自体はあっても、いわゆる「Web系」の知識はゼロからのスタートでした。繰り返しますが、HTMLすら知らなかった状態から、独学ベースで上記技術スタックをアプリに盛り込めるレベルまで到達することができました。

独学ベースでの学習になると、「どの学習教材を選ぶべきか」というところから自分で考える必要があります。いろいろと紆余曲折ありましたが「これは役に立った！」と思うものを厳選し、時系列に沿ってお伝えします。

※下記サービスのWebリンクや、ロゴ画像、ホームページのスクリーンショットについては、事前に各運営者様に使用許可をいただいております。改めまして運営者皆様、利用快諾していただきありがとうございました。

3.1 Progate

皆大好きProgate。今からエンジニアを目指す方は、全員ここから入門して間違い無いでしょう。

URL: https://prog-8.com/

自分は手当たり次第に色々な講座をやってみていましたが、

HTML&CSS

Javascript(ES6)

jQuery

Ruby

Ruby on Rails

次いで

Command line

Git

SQL

辺りを押さえておけば十分だったかと思います。

各講座の序盤のレッスンは無料会員でも受けることができますが、本気でエンジニアを目指すのであれば、有料会員限定のコースも含めて取り組んでいきましょう。

これだけでもそれなりにボリュームはありますが、挫折しにくいよう学習ステップがかなり細かく設定されているので、初心者にとっても易しいつくりになっています。

ただ、Rails講座だけはさすがに難易度が高かったです。。。これは、Progateさんの講座の作り云々ではなく、Webフレームワークという概念が初学者にとって「始めまして」になるので、多少仕方がない部分ではあると思います。

1周目で全体像の把握、2週目以降で詳細理解に努める、というスタンスでよいかと思います。

3.2 Ruby on Railsチュートリアル

皆大好き(?) Rails チュートリアル。

URL: https://railstutorial.jp/

色々賛否ある教材ですが、無料かつ、ここまで体系的に「RailsのWebアプリ開発」を学べる教材は他にないと思います。

本教材の謳っているところでもありますが、「単にRuby, Railsの学習に終始せず、Webアプリ開発の全体像を俯瞰する」ものですので、本教材での知識は、他言語・他フレームワークで開発をする場合でも大いに活きると思います。

確かに、当教材に対する否定的な意見はいくつか見受けられ、

テストフレームワークとして、国内企業でデファクトスタンダードになっているRspecではなく、Railsに標準搭載されているminitestを使用している

採用技術が古くなってきてしまっている

という点がよく指摘されています。

ただ、前者については、株式会社YassLab代表のコチラのYoutube動画の動画でも説明がある通り、「かつて(第２版まで)は Rspec を Rails チュートリアルでも採用していたが、Rspec 自体の学習コストが高いこともあり、それによる脱落者を多く出していた」という背景を受けてのものになります。

また後者については、例えば現在の Rails企業の多くは、Rails単体のアプリケーション(フロントはjQery/bootstrap)ではなく、APIとしてRailsを利用し、フロントはJSフレームワーク(Vue.jsやReact.js)を使うのが一般的になってきています。しかし、Rails初学者が、いきなりAPI開発から始めるのは、理解の階段を飛ばしすぎている、というのも事実でしょう(これについては、同者のコチラのYoutube動画も参考になるかもしれません)

つまり、Rails チュートリアルは「Railsを初めて触る人がなるべく挫折しにくい難易度設定を目指す」ということを念頭に置いた教材であり、最前線の現場で使用されているような本格的なRailsの習得の橋渡しをするようは役割である、と考えることができるかと思います。逆に、これ以上現場に近づけた本格的な内容にしてしまうと、それこそ多くの初学者が挫折してしまうと思います。

したがって、Rails初学者は、今この時代であっても、自信を持って当教材取り組んでよいと思います。少なくとも自分は、この後にも続くRails学習において、ベースとなるような知識をつけることができた、と感じています。

ただ、いくら難易度を落としているとはいってもRails初学者に取ってはかなり難しく、かつ量も膨大であるのは事実です。そのため、Railsチュートリアル完走を一つのマイルストーンとして設定し、内容につまづいたら「ひたすらググる」あるいは「適宜Progateに戻る」という進め方が効率的かと思います。

私も、一度はあまりの量と難易度に挫折してしまったのですが、社会人としてすでに働いており、ある程度お金に余裕があったので、動画版を購入して最後までやり切りました。個人的には、人が解説してくれている形式の方が理解がスムーズで、モチベーションの維持もしやすかったで、お金に余裕のある方にはオススメです。

Railsチュートリアルで身につく知識を整理すると、

バックエンド: Rails(シングルアプリケーション)

フロントエンド: jQuey+bootstrap (Railsの一部として内包)

テスト: minitest

開発環境: AWS cloud9

デプロイ: Heroku

全くの初心者からWebアプリとして求められる一通りの機能を実装し、本番環境へデプロイするところまでできるのは、やはり教材として素晴らしいと思います。

しかし先ほども述べた通り、当教材はあくまでも橋渡しの位置付けです。未経験からの転職という自分自身の立場を鑑みると、Web系企業への転職用PF作成の準備としては、技術面でまだ心許ない、と考えました。

改めて複数企業の採用ページから実際に企業で使用されている技術を確認し、上記の学習知識と比較して整理をすると、

フロントは、Vue.jsやReact.jsといったJavaScriptフレームワークを使用するのが一般的。それに伴い、Railsは単独アプリとしてではなく、APIモードで開発する

テストフレームワークは、minitestではなく、Rspecがデファクトスタンダード

開発環境はPCローカルに構築する(Vagrantで仮想マシンを構築するか、Dockerでコンテナ化するか)

アプリケーションのデプロイは、小規模であれば Heroku を使うこともあるが、企業が提供するような中・大規模なアプリケーションであれば、AWSやGCPなどをよく用いられる

次に習得すべきは、ここの技術領域であることが分かりました(個人的な話ですが、この辺りの時期からエンジニア採用ページに書かれている各技術がスタックが、どういった内容であるかが理解できるようになってきており、成長を実感していました)。

Railsチュートリアルを完走した方は、完走者向けのロードマップ紹介ページもありますので、まずはここを見てみるものよいかと思います。しかし私は、洗い出した上記項目をより体系的に学ぶことができるものがないかと考え、自分なりに色々と教材を探してみた結果、以下のサービスに辿りつきました。

3.3 Take off Rails

URL: https://freelance.cat-algorithm.com/lp/take-off-rails

『あなたを「初心者エンジニア」から「現場で活躍できるエンジニア」まで引き上げます。』というスローガンを掲げた教材とメンターがセットになったサービスで、Rails チュートリアルと実際の企業の間の穴埋めを狙った内容になっています。

基本的にはすでに作成された教材に則っとりながら自分のペースでアプリを開発していくのですが、都度 Slack でメンターさんに質問を投げることができるというのが大きな特徴です。。

最終的な教材のゴールとしてはQiitaのクローンサイトを開発することになります。これの技術スタックは下記の通りです。

バックエンド: Rails APIモード

フロントエンド: Vue.js (ソースコードは作成済みのものを使用。あくまで Rails との繋ぎ込みまでを扱う)

テスト: Rspec(+Factory_bot)

開発環境: ローカル + DB(MySQL) は Docker コンテナを利用

アプリのデプロイ: Heroku

その他: CircleCI による rspec, rubocop の自動化

※ 私の当サイト用のリポジトリ： https://github.com/ddpmntcpbr/qiita_clone

Railsチュートリアル時点での技術スタックと比べると、かなり実務に近い技術が盛り込まれていることが分かるかと思います。

こちら、決して安い金額ではないサービスだと思います(スクール等に比べれば全然安いですが)。ただ、当時欲しいと思っていた知識が一気に身に着けられると考えて、購入を決意しました。

結果、良い買い物だったと思います。自分が学びたい内容がきれいに体系化されていたこともそうですが、何より、教材内容についてメンターさんへ質問ができるのも有意義だと感じました。遅くとも24時間以内にはレスポンスが返ってくるのもありがたく、「料金分を回収してやるぞ！」という気持ちで、たくさん質問させてもらいました笑

本教材では、上記技術の学習だけでなく、

Git commit の適切な粒度や、コミットメッセージの書き方

Github での PR の出し方や、コードレビューの流れ

Slack でのやり取り(意図が伝わりやすい質問の仕方など)

といった、「独学ではなかなか身につかない」けど「チーム開発では必須になる」ような周辺知識について学べた点も、非常に有用だったと思います。Railsチュートリアルの内容がおおよそ理解できていれば前提知識としては十分な難易度で、大きく挫折をすることがなかった点もプラスです。

さて、ここまでで、Railsに関しては、比較的モダンな開発手法に触れることができました。

しかし、当教材ではあくまでも Rails の開発に的を絞ったものであり、フロントエンドは既存のソースコードを流用する形での学習でした。この教材の内容を自身の転職用PFに組み込むためには、フロントエンド側についても自身で開発する知識が必要と考えました。

フロントエンドフレームワークの選定について、第２章でもお伝えしたとおり、「Reactの方がなんとなくよさそうかなー」と考えていたところ、次の教材を見つけたことをきっかけに、正式に React の学習を始めることにしました。

3.4 【とらゼミ】トラハックのエンジニア学習講座

現役の React エンジニアであるトラハックさん ( @torahack_ )が、Youtube上で公開している講座で、Reactについて基礎の基礎から学ぶことができます。

動画チャンネルURL: https://www.youtube.com/user/1492tiger

こちらの教材の特長は、

Reactの基礎の基礎から体系的に学べる( Progate の JavaScript 講座完了が受講目安)

動画によるハンズオン形式

教材範囲にモダンなフロントエンドの開発手法を含む( Redux 等)

動画のほぼ全てがYoutube上でなぜか無料公開されている

特に最後については完全にバグとしか思えない点で、Udemyなどで有料販売されていても動画講座と比べても遜色ないクオリティだと思います。

動画教材にありがちな「準備した原稿丸読み」のような堅い口調ではなく、フランクな若手予備校教師の授業(?)のような語り口のため、硬い喋りが苦手な人にもお勧めできます。私は復習のために、一度見た動画を耳だけで聞き返したりして、記憶の定着を図りました。

講座はいくつかのシリーズに分かれており、私が視聴をしたのは、

1.『日本一わかりやすいReact入門』シリーズ
2. 『日本一わかりやすいReact入門【実践編】』シリーズ
3. 『日本一わかりやすいReact-Redux入門』シリーズ

の3シリーズです。

最終的な成果物の技術スタックは、

create-react-app

Redux & redux-thunk

Material-UI

Firebase： Google が提供する mBaaS。バックエンド＋インフラを手軽にセットアップできる

です。

※ 私のGithubリポジトリ: https://github.com/ddpmntcpbr/react-ec-app

こちらの動画については、学習備忘録記事をQiitaに投稿しております。よろしければこちらもご参考下さい。

参考ページ: 『日本一わかりやすいReact入門【実践編】#1~5 学習備忘録』

本学習講座を全て受講するためには、有料コミュニティ『とらゼミ』への加入が必要になりますが、筆者は無料公開範囲の動画で必要な知識は十分に身に付いたと感じたため、加入はしておりません。（代わりの記事として書くことで、宣伝として少しでもお役に立てればと思っています笑）

さて、ここまででフロント側も自力で開発ができる基礎が身に付きました。これくらいの時期に並行してアプリのコンセプトが決定していましたので、いよいよポートフォリオ作成に取り掛かり始めました。

しかし、開発を始めるといくつも壁が出てきます。基本的にはググりながらの解決をしていきましたが、どうしても解決できないエラーにもぶち当たりました。特に、

ReactとRailsの繋ぎ合わせ

AWSでのアプリの公開方法

その他インフラ知識全般

あたりが、個人的な難所でした。その過程で頼らせてもらったのが、次のメンターサービスです。

3.5 TechTrain

有名企業のエンジニアから実務を学べるオンラインコミュニティ です。

URL: https://techbowl.co.jp/techtrain

特長を列挙すると、

現役エンジニアであるメンターさんと、1 on 1でのオンライン面談が可能

メンターの方々の技術領域は多種多様

全てのメンターと面談が可能で、技術トピックに応じて切り替えることが可能

面談はこちらからのタイミングで入れることができる

なぜか全て無料で利用できる

はっきり言います。これだけのことができて完全無料なのは完全にバグです。これからエンジニア就職を目指しているU30の学生・社会人は、全員登録した方がいいレベルです

TechTrain の中ではいくつかの Mission が設けられており、それをメンターと一緒に取り組んでいくことで知識を習得していく、ということが可能です。 Mission は実際のIT企業とのコラボで作成されており、中には「Missionをクリアできた人は一次面接をスキップできる」のような特典もついていたりします。

ただ私は Misson には取り組まず、あくまでの個人開発のサポートとして利用させてもらっていました。基本的には自身の既存知識とググり力でPF作成を進めつつ、どうしても解決できない課題が出てきたときにピンポイントで面談予約を入れる、というイメージで、個々人の利用したい形式/ペースで利用できる点も大変ありがたかったです。

異なる技術領域を持ったエンジニアの方々全員と面談をするが可能なため、Rails, React, AWSそれぞれで、別のメンターの方に質問をさせてもらっていました。

特に自力での解決が難しかったのがAWS周りの本番環境構築で、本サービス無しでは乗り越えられなかったと思います。

AWSのことをAWS現役社員に無料で聞けるサービスと表現すれば、このサービスのやばさが伝わるかと思います。

最終的には、自身のググり力 + TechTrain で都度メンターを利用、を繰り返すことで、無事アプリを完成させることができました!

3.6 番外編

上記以外で役に立ったものについて、ざっくばらんに紹介します。

Udemy 『Git：はじめてのGitとGitHub』

無料で Git の基礎を学べる講座です。「Gitよう分からん！」って人は、まずこれから触れてみましょう

 『キタミ式イラストIT塾基本情報技術者』

基本情報処理の定番本です。コンピューターサイエンス領域の基礎知識が体系的に学べます。イラストが豊富であり、文章表現も柔らかいので初心者にも優しいです。資格自体の取る/取らないに関わらず一読をオススメします。

『米国AI開発者がゼロから教えるDocker講座』

Dockerについて一から学べる動画教材です。作者様はデータサイエンス領域の方ですが、Webアプリ開発を目的とした人であっても問題ありません（実際に、講座後半では、docker-composeを利用したRailsコンテナの構築まで扱っています）

非常にボリューミーな内容にも関わらず、Udemy講座の中ではかなり良心的な価格設定です。

『【AWS 入門】EC2とDockerでHello Worldしよう』

AWSについて何にも分からない状態から、「nginxだけのシンプルなコンテナアプリを動かす」ところまで、ハンズオン形式で学習ができます。

AWSのとっつきにくさは、「①インフラの概念が分からない」「②専門用語が分からない」に集約されると思います。まずは手を動かしながら、AWSでアプリをデプロイ流れを全体像で掴むことができます。

3.7 アプリの改善点

一通りアプリを完成させてみて、初めて見えてくる改善点が多くありましたので、合わせて列挙します。

AWSサーバー代高すぎ！！！

スケーラビリティの高い中・大規模向けインフラ構成になっているため、サーバー代がめっちゃ高い笑

長く公開するためには、どこかのタイミングで無料サーバーへ移管する必要があるかなと思います。Heroku の無料枠で上手にやりくりできれば、解決できるかもしれないです。

フロントエンドは Next.js + Typescriptで実装したい

Next.js はレンダリングのタイミングを制御できるので、OGP情報の保持が簡単に実現できます。

また、それ以外でも、

ルーティング設定が簡単

パフォーマンスをよくするような機能も豊富

Typescriptの導入が用意

というメリットもあり、とても気になっているフレームワークです。次、全く同じアプリを開発するとするのであれば、絶対に採用したい技術です。

デザインがあやしい気がする・・・？

アプリを開発して気づいたのは、アプリにおけるデザインの重要性です。

これを思った理由は単純で、開発途中で「なんか自分のアプリ、イケてなくない？」と感じたからです笑

Webアプリにおけるデザインは、単なるお洒落さに関するものだけでは決してありません。デザインは、ユーザーにとって必要な情報を適切に配置することであり、ユーザーの価値提供のための最前線領域です。

ユーザー側から価値提供の流れ(バリューチェーンと表現するのでしょうか)をざっっっくり並べると、

ユーザー -> UI/UXデザイン -> フロントエンド -> バックエンド -> インフラ

のようになっていると思っています。

「エンジニアになろう！」と意気込んでから、後ろ3つについてはそこそこ勉強してきました。しかしデザイン領域については、開発初期は完全素人の状態で、途中までは勘でやっていました。。。

一応、付け焼き刃程度ではありますが、デザインの名著である『ノンデザイナーズ・デザインブック』に目を通し、途中からは意識できる範囲ではデザインのことを意識して、フロントを実装しました。

うまく取り込めているかは分かりませんが、少なくとも「デザインはセンスではなく論理」であることが学べただけでも、よい勉強になりました。こちらの書籍も、転職用PF作成者にオススメしておきます。

4. さいごに

以上、大変長い記事でしたが、最後まで読んでいただきありがとうございました。タイトルでは「学習ロードマップ」と銘打っておきながら、私自身の思考プロセスや価値観についても多く書かせてもらいました。

「エンジニアになりたい！」と思い立ってから、学習自体はほぼ一人で淡々と進めてきました。しかし、ほぼ独学でここまで学習を進めることができたのは、多くの先輩エンジニアの方々が様々な情報をインターネットに投稿し、それをオープンに取得できる環境にあったからだと思っております。

それであれば、次は自分自信が、他の駆け出しエンジニアの方々の助けになるような情報を発信できれば、と思い、この記事を書くこととしました。参考になったという方がいらっしゃったら幸いです。

是非LGTM、ストック、twitterでのシェアお願いします！また、私自身もtwitterをやっておりますので、気軽にフォローしてもらえるとうれしいです(^^)

よろしくお願いします！

Twitter: https://twitter.com/ddpmntcpbr
Github: https://github.com/ddpmntcpbr/rails_react_docker

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T14:13:23+09:00

【未経験開発 Rails/React/AWS/Docker/CircleCI】独学＋メンターでここまで出来た！Web知識ゼロからモダンな技術アプリ開発までに利用した5つのサービス

0. はじめに

こんにちは！辻野(@ddpmtcpbr)と申します。

当記事は、「Webエンジニアへのキャリアチェンジを目指している開発未経験者が、モダンな技術を備えたアプリを開発するまでの学習過程」についてまとめたものです。

現在筆者は非IT系企業の社員として働いており、Web開発エンジニアとしての実務経験はありません。

そんな筆者がWebエンジニアとしてのキャリアチェンジをするためのポートフォリオとして、本アプリを開発しました。

学習開始から現時点までにおいて、プログラミングスクール等には通っておらず、学習はほぼ全て独学&一部メンターサービス利用の布陣で進めてきました。

独学中心でアプリ開発に挑戦したい、ポートフォリオを作成してWebエンジニアへのキャリアチェンジを進めていきたい、と考えている方々にとって、参考になればと思います。

※2021/3/10追記

記事を投稿してから約1日で、5700view、110LGTM、90ストックをいただくことができました！多くの方に見ていただき大変ありがとうございます?‍♂️皆様のおかげで、人生初のQiitaデイリーランキングにも載りました！

告知Tweetに対しても180以上のいいねをしてもらい、大変ありがたい限りです?まさかこれほど多くの方に見ていただけるとは予想しておらず、嬉しい反面、身が引き締まる思いです

開発アプリ概要

アプリ名：積読解消アプリ「Yomukatsu!」

「あなたの積読解消をサポートします」をスローガンに掲げたSPA風Webアプリです(”風”の詳細は後述)。

読書メンタルマップという手法を用いて、ユーザーの書籍完読に向けたモチベーション維持をサポートします。

Web URL: https://yomukatsu.com/

【3分動画】Yomukatsu 字幕解説

アプリの使い方を3分でまとめています。

使用技術

Backend: Rails ( API mode / Rspec / rubocop) + Nginx ( upstream puma-socket )

Frontend: React ( create-react-app / Redux / Material-UI / eslint&prettier)

Infra: AWS ( ECS Fargate/ ECR / RDS / ALB / Route53 ), Netlify, Docker&docker-compose, CircleCI

各項目の詳細は後述しています。

インフラ構成

モダンな技術を採用したWeb系企業が提供している、中・大規模なアプリケーションを想定したインフラ構成にしています（そのため、個人開発アプリとしてみるとちょっと仰々しいかもです(;’∀’)）

詳細は後述しています。

機能一覧

ユーザー利用機能

Twitterアカウントを利用したユーザー登録(OAuthによるSNS認証)

ゲストログイン機能

Google Books APIを用いた書籍検索機能

Google Books、Amazon、楽天ブックスへのリンクボタン配置

Twitterシェア機能

ハッシュタグ「#yomukatsu」付きTweet

Twitter card 表示

Twitter card用にリサイズした書籍画像をAWS S3へ保存・管理

Redux による state 管理を活用したローディング画面

Slack Incomming Webhookを利用したお問い合わせ機能

Route53 による独自ドメイン + SSL化

非ユーザー利用機能

Netlify の Pre-reidering 機能活用による動的なOGP情報の保持（ Twitter card 表示用）

Docker による開発環境の完全コンテナ化

CircleCI による自動 CI/CD パイプライン構築

CI: Rspec, rubocop, eslint&prettier

CD: AWS ECR

その他セキュリティ対策(XXS, CSPF等)

まず触ってみてもらうのが一番良いかと思います！今回はフロントエンドに React を採用しているため、メニューモーダルの開閉や通知バー表示など、アニメーション的な表現も実装できているのが伝わるかと思います。

ゲストユーザー機能もありますので、気軽に利用してみてほしいです！レスポンシブにも対応しています。(推奨ブラウザはChrome、Safariになります）

アプリURL: https://yomukatsu.com/

※現在α版としてのリリースのため、配信内容が予告無く変更される可能性がございます

あわせて、 Githubも公開していますので、よかったら参考にしてください。

Github URL: https://github.com/ddpmntcpbr/rails_react_docker

この記事について

当記事は3章構成になっております。

まず、「1.自己紹介」で、簡単に自己紹介をさせていただきます。

次に、「2.開発アプリ解説」で、今回の開発アプリ開発について、コンセプト決定の流れから、実装機能/技術スタックについて詳しく紹介します。「転職用PF作りたいけど、どんなアプリを作ればいいか分からない」という方にとって、参考になることがあれば幸いです。

最後に、「3. 学習ロードマップ」で、Web知識ゼロだった筆者が、当アプリの開発にまでに利用した5つの教材およびサービスについて、時系列に沿って紹介したいと思います。特に独学では、「まず何を学べば良いのか」「どんな教材を選べば良いのか」というところから自身で考える必要があります。そういった方々にとって参考になり得る情報と思います。

1. 自己紹介

1.1 筆者スペック

20代後半男

工学部機械系修士卒 → 非IT系日系製造業技術開発職(現職)

大学から現職において、データ分析ツールとしてプログラミングを経験(matlab / python)

Webエンジニアへのキャリアチェンジを目指し、社会人になってから独学を開始

大学入学以降、授業や研究データの分析ツールとしてプログラミングに触れる機会はありました。もともと自動化や効率化に興味があったことからプログラミングにだんだんとのめり込み、研究室ではプログラミングに多く触れられそうな研究テーマ(データ分析系)を選びました。

したがって、「プログラミング自体が完全に未経験」というわけではありませんでした。しかし、いわゆる”Web系”の知識は社会人以降の独学を開始するまではゼロ、という状態で、最初は HTML すら知らないところからのスタートでした(￣▽￣;)。そのため当記事では「Web知識ゼロ」という表現をしています。

キャリアチェンジ志望の理由は、ざっくりと言えば、

1. もっとプログラミングがしたい
2. モノづくりで誰かの役に立ちたい
3. 非効率・非生産的な仕事を無くしたい

ここについては当記事の趣旨ではないので、詳細については省略します。

2. 開発アプリ解説

2.1 コンセプト方針

転職用PFアプリのコンセプトを決めるにあたり、満たすべき用件としては、下記3点を考えました。

(a) 実際の企業が採用しているようなモダンな技術を盛り込む
(b) 具体的な解決課題を明確にする
(c) サービスの利用が個人で完結する

(a) 実際の企業が採用しているようなモダンな技術を採用する

未経験からエンジニア転職において、高品質なポートフォリオは必須と考えました。

「モダンな技術をポートフォリオに組み込むことで、技術力の高さをアピールする」というのが基本的な考え方になるとは思いますが、個人的な解釈としては、ポートフォリオで証明すべきは「技術力」ではなく「自走力」だと考えています。

ぶっちゃけた話、実際の現場を経験したエンジニアと比べれば、未経験者間での能力差というものはどんぐりの背比べのようなものだと思います。多くの企業が「実務経験1年以上」をエンジニアの採用項目にあげていることからも、実務経験というのはそれだけ重い価値があり、未経験者とは大きな隔たりがあるのだと思います。

したがって、ポートフォリオの技術レベルの高さそのものはあまり重要ではなく、そこに到達するまでの過程の方が大事であり、「自走力＝必要な情報は自らキャッチアップして吸収する能力」があることを示す方が、企業人事側としては採用しやすいのではないか？と考えました。

「スクールの制作アプリをそのまま提出する未経験者が足切りされてしまう」という話は多く聞きますが、これはそのアプリの技術力が低いからではなく、そのアプリから当人の「自走力」が主張できないから、だと私は考えています。私が独学ベースにこだわったのは、単純にお金の問題だけではなく、独学ベースでアプリを開発することができれば、自然とそれが「自走力の証明」につながると考えたからです。

今回のアプリにおいては、「独学:メンター=8:2」くらいの割合で、上記技術を採用できるラインまで行くことができています。「メンター利用は独学からは外れるのでは？」という指摘もあるかもしれませんが、

プログラミングでは、個人ではどうにもならないようなエラーに遭遇してしまうことが多々ある

実際に企業に入ってからは、先輩エンジニアの方々に分からないことを質問しながら業務を進めることになるため、「質問力」も重要な能力である

完全独学オンリーだと、誤った癖が身についてしまっているリスクが高くなる

といった観点から、独学者が適宜メンターサービスを利用することは、かえって採用人事側にとって安心感を与える材料になるのでは、と考えたので、自信を持って「メンターサービスを使いました」と主張しています。

※ 具体的なモダンな技術リスト

Rails API + JSフレームワーク(React.js)の構成

Dockerで実行環境を完全コンテナ化

Herokuではなく、AWS でアプリをデプロイ(ECS Fargate & ECR)

Circle CIによるCI/CDパイプラインの構築

(b) 具体的な解決課題を明確にする

さて、前章とは一見真逆のことを言いますが、アプリ開発において、モダンな技術を採用することそのものには本来何の価値もない、と考えています。

なぜなら、アプリの目的はあくまでも「ユーザーにとって価値を提供できるか」であり、技術はそれを実現するための手段でしかないはずだからです。(保守・運用面でのメリットも考えられますが、保守・運用の最終目的もユーザーへの価値提供であることから、この点も包含した解釈になります)

これは、技術というものを下に見ているというわけでは決してありません。むしろ「新しい技術をどんどん使ってみたい！」という技術に対する好奇心、探究心は人一倍強い自負があります。現職はIT系ではありませんが、技術開発職という立場で業務に取り組んでおり、知的好奇心を満たせるという意味では、今の仕事に面白みを感じています。

しかしながら、かつては行き過ぎた技術先行思想によって「手段の目的化」が発生し、「最新技術を駆使した誰にとっても役に立たない技術」を開発してしまったという苦い過去の経験があったりもします。結果として「やっぱり技術は人の役に立ってなんぼ」というのが、約3年間技術職として働いてきて培った、技術者としての小さな矜持だったりします(この辺の話は直接お会いした方にはお話できるかと思います)

転職用PFであれば、技術ありきな考え方になることはある程度は仕方がないことでしょう。しかし「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」くらいのことは転職用PF作成においても考えていいんじゃないかな？と思いました。あるいは、もう少し目線を下げて「自分が欲しいものを作ろう」という程度でも十分でしょう。大事なのは、まず課題があり、それを解決する手段として技術があるという順番だと思いました。

もちろん今回の開発アプリは転職用PFが趣旨である以上、中には「技術力を証明したいから」という理由で選定した技術もあり、全てに対して課題が明確だったわけではありません。また、初心者の個人開発アプリがいきなりバズることは現実的には厳しいとは思います。しかし、そこを目指す姿勢があるかというのは、エンジニアとして本格的にキャリアを進めていく上では、長期的には大きな差異になると考えています。

また、

課題が明確な方が採用した技術や実装した機能の根拠も明確にできるため、開発の方針を立てやすい

自身がユーザー目線に立てることで、改善点を見つけやすい

純粋にモチベーションを維持しやすい

といった点でもメリットもあると感じましたので、この方針は間違っていなかったと思います。

(c) サービスの利用が個人で完結する

「せっかく作るのであれば、誰かにとって役に立ち得るものを目指そう」を、もう一歩深く考えた方針です。

例えば Rails を対象として考えたとき、一般的な転職用PFとしては、TwitterライクなSNS系アプリや、メルカリライクなEC系アプリが多いかと思います。

理由は、ユーザー認証、CRUD操作、DB間のリレーションなど、基本的なサーバーサイド技術を一通り抑えられるものであるから、だと思います。「Railsの一般的な知識を持っていることを証明する」手段と考えれば、妥当な方針でしょう。

しかしながら、未経験者が転職用に開発した上記アプリが実際にユーザーに継続して使われるということは、まず無いでしょう。SNS系アプリは「ユーザー数が多ければ多いほどサービスとして質が高まる」性質があるため、アプリとして軌道に載せること自体が非常に難しいです。EC系アプリは BtoC であれば出品企業がいないとサービスが成り立たない、CtoCであればより SNS として要素が強まる & いよいよメルカリで十分、という壁があります。

これらアプリの難しさは、ユーザーどうしがつながることを前提としている点にあります。裏を返せば「個人で完結するアプリであれば、活路はある」とも言えると考え、この方針でコンセプトを詰めていくことにしました。

2.2 コンセプト内容

上記3点を念頭に置きながら、自分自身の生活の中で"課題"を探し、最終的にたどり着いたものが「読書メンタルマップ術の電子化」というコンセプトでした。

そもそも皆様は、読書メンタルマップ術というものをご存知でしょうか？

読書メンタルマップ術とは、ハーバード大学の先生が提唱している積読解消術です。読破したい書籍に対して、

1. 完読したい本について、それを読む“理由”や“目的”を3つ、紙に書きだす
2. 飽きてきたら、それを見返す

を繰り返すことで、完読までモチベーションを維持するというシンプルな読書手法です。

積読というものは、だいたい「最初は読む気があったけど、次第に読む気がなくなってしまった」書籍です。この「最初の読む気」を事前に明文化・保存しておくことで、いつでも最初の頃に新鮮な気持ちを取り戻せるようにしておこう、というイメージになります。

自分自身、実際に活用している技術ではあるのですが、少し困ったことがあります。それは、電子書籍との相性が悪いことです。

通常であれば紙とペンを用いるものですが、例えば出先でスマホやタブレットで電子書籍を読んでいるような状況では、必ずしもこれらの道具があるとは限りません。特に私は、外に出る時はあまりものを多く持ちたく無い性分なので、外ではスマホと財布くらいしか持っていないことが多いです。

仮に持っていたとしても、例えば電車の中で紙とペンを出して色々と書き始めるのは、少し億劫だったりします。

「これを全部ペーパーレスで完結できるようなアプリがあったら便利だな」と思ったのが、このコンセプトを思いついたきっかけになっています。

もちろん、これだけであればスマホのメモ帳だけでもできてしまうものですが、このアプリには、

Google Books APIを活用した書籍検索・保存機能

メンタルマップ作成のヒント機能

Google Books, Amazon, 楽天ブックスへのリンクボタン配置(特に書籍レビューはメンタルマップ作成の大きなヒントになる)

Twitterでの読書仲間への気軽なシェア機能

といった機能が備わっており、より読書メンタルマップ術を使用しやすい環境を整えています。

先ほどの「2. 具体的な解決課題を明確にする」に照らし合わせて考えると、このアプリの解決課題は、ユーザーの積読を解消すること、もっと言えば、読書メンタルマップ術をペーパーレスで実行できるすることで電子書籍で読書するユーザーにとっても扱いやすくすること、になります。

また、「3. サービスの利用が個人で完結する」も満たしています。当アプリには、ユーザー同士がつながる機能は一切実装されていません。

代わりとして、Twitterとの連携にはかなり重きを置いて実装機能を決めました。具体的には、

Twitterアカウントを利用したユーザー登録

ワンタップでハッシュタグ付きツイート

充実した Twitter カード表示

を機能として実装しています。原則的には個人でサービスが完結しつつも、ユーザーどうしの繋がりはTwitter内の既存のネットワークに乗っかる、ことを狙ったコンセプトになっています。

2.3 技術スタック

再度、インフラ構成を載せます。

この内容について、ひとつひとつ解説します。

Back-end

Rails API + Nginx の組み合わせにしています。

サーバーサイドフレームワークとしては他にも Laravel, Django, Node.js などもあります。恐らく大体のことは、どれを選んでも実装・実現できる、と思うのですが、その中で今回 Rails を選んだ理由は、

採用している企業数が多い

日本語の教材が豊富なため学習のハードルが低い

国内コミュニティが発達しているため、インターネット上での日本語ドキュメントが豊富

最初の学習言語として Rails を選択する初学者の方は多くいるかと思います。その一方で、「Railsはオワコン」という説が各所で言われていることについて、不安に感じる初学者の方もいると思います。

この点に関して、あくまで個人的な見解を述べますと初学者であった自分が、少なくとも最初に学ぶ言語/FW として Rails は間違いではなかった、と考えています。

正直、初学者である私には、「なぜ Rails がオワコンであるのか」について技術ベースで語ることはできません。しかし、

現時点で Rails を採用している企業の絶対数は多く存在すること

日本国内において、Rails に替わるサーバーサイドのデファクトスタンダードな技術が、まだ定まっていないこと

は事実と言ってよいかと思います。

もしかしたら、長期的に見れば日本国内でも Rails を採用する企業が減っていく流れにはあるのかもしれません。しかし、微分値と絶対値はセットで捉えないと判断を誤ることになります。初心者が目指すべきは「今すぐに仕事を得られる技術を身に着けること」であり「将来必要になってくる技術」ではないはずです。

また、オワコンというのは裏を返せば、技術的に枯れていて、初心者にとっては学びやすい言語/FWである、とも言えます。

Railsは日本国内での(過去含めた)使用者が多いため、関連する日本語のドキュメントがインターネット上に多く存在します。事実、Rails開発で遭遇するエラーは、Google検索すれば何かしらの日本語のサイトがヒットします。

最先端の技術は過去の技術の欠点を補う要素を持って生まれてきているのは事実ですが、検索しても欲しい情報が見つからなかったり、あったとしても英語ドキュメントだけだったりします。私自身は、このアプリの開発を通じてWebフレームワークに基本的な概念が身についてきているため英語ドキュメントでも読めるようになってきましたが、ベース知識すら乏しい状態からいきなり英語のドキュメントを読み解かないといけない状況になっていたら、途中で挫折してしまったかもしれないです。

以上が、私が最初の言語/FWとして Rails を選んでよかった、と考えている理由になります。

主要gem

devise_token_auth： APIモードでの devise。トークン認証を簡単に実装

twitter_omniauth：Twitter認証を簡単に実装

active_model_serializer： Rails APIからのレスポンスJSONを制御

imageMagic: 画像のリサイズを実行。特に、Twitter card用に書籍画像をリサイズする際に使用

aws-fog/carrierwave: リサイズした書籍画像を AWS S3 に保存

rspec：デファクトスタンダードになっているRubyテスト用フレームワーク

rubocop： Rubyの静的コード解析

TwitterアカウントでのOAuth認証は、過去の実装例が少なく、非常に苦労したところでもありました。しかし、「Twitterとの連携を重視」という今回のコンセプト上では絶対に欲しい機能と考え、頑張って実装しました。

AWS S3については元々採用予定はなかった(Google Books APIの画像リンクをそのまま引っ張ってくる予定だった)のですが、Twitter card で書籍画像を表示させる時にどうしても画像サイズを適切に制御する必要が出てきたので、imageMagic と合わせて Rails で画像リサイズ & S3保存、を実装することにしました。

Front-end

今回フロントエンドとしては、JSフレームワークであるReact.jsを採用しました(細かいこと言えば React はフレームワークではなくライブラリですが、ここではフレームワークとして扱います)。モダンな技術採用を謳う以上、Rails + jQuery/bootstrap の構成では心許ないと考えました。

JSフレームワークとしては、国内企業での採用状況から考えるに、React.jsかVue.jsか、の二択になると思います。その中でもReact.jsを選んだ理由は、

自分が調べた範囲では、バックエンドに Rails を採用している企業群のうち、フロントに React を採用している企業の割合が高かった

Vue.js よりも規約が厳格であり、初学者の自分であっても自然と可読性の高いコードを書くことができそう

たまたま、React を効率的に学べる良い教材を見つけた

特に最後については、第３章で後述しています。

アプリ開発を通じて React.js が割と気に入ってきたので良い選択だったとは思いますが、この点に関してはどちらを選んでも間違いではなかったかな、とは思います。

主要ライブラリ等

create-react-app: Facebookが提供するオープンソースのReact開発パッケージ

Redux: Stateの一元管理するフレームワーク。Redux関連ファイルは、reducksパターン則って管理

Redux-thunk: Redux state の非同期処理を制御

react-helmet: 動的なmetaタグの挿入によるOGP情報の保持(Twitter card用)

react-share: Twitter含めたSNSシェア用ボタンを簡単に配置

Material-UI ： Google が提供する UI コンポーネントライブラリ。簡単におしゃれな UI コンポーネントをアプリ内に配置できる

eslint & prettier: javascriptに対する静的コード解析。eslint は create-react-appに標準搭載されているものをベースに少しプラグインを追加 & prettier はイチから導入

今回はユーザーの利用シーンを考えると、Web上でもネイティブアプリのようにサクサク動く、JSリッチなアプリケーションにしたいと考えました。この点からも、jQuery+bootstrap ではなく React.js を採用してよかったと思います。

React の実装には、特にMaterial-UIが強力で、開閉モーダルや通知バー表示などのアニメーション演出や、ページ全体のレスポンシブ対応などがかなり簡単に実装できました。このライブラリを使えたというだけでも、React を採用した価値があったと思えるほどでした。

Infra

Docker/docker-compose

開発環境は、全てDockerコンテナ内で完結させています。docker-compose.ymlのサービス構成としては、

db: MySQL

api: Rails

web: Nginx

front: Node.js (React)

としています。

後述しますが、AWS ECS(Fargate)へのコンテナデプロイを利用することで、開発環境と本番環境の差異を小さくすることができています。

AWS(Amazon Web Service)

バックエンド( Rails + Nginx )のデプロイに使用。Railsチュートリアルなどではアプリの本番環境へのデプロイにはHerokuを用いることが一般的ですが「モダンな技術を採用したい」という観点から、AWSに挑戦しました。

稼働させるまでめちゃくちゃ苦労しました。ここを完全独学で完結させるのは相当しんどいと思います。第３章で触れていますが、AWSの学習については、メンターさんをかなり頼らせてもらいました。

※ 利用サービス

ECS (Fargate): コンテナ向けサーバーレスコンピューティングエンジン。この中に Rails と Nginx の Docker イメージを入れて稼働させる

ECR: Rails と Nginx の Docker イメージを保存しておくリポジトリ

RDS (MySQL): AWS が用意しているスケーラブルなデータベースエンジン

ALB: 負荷分散を担うロードバランシングサービス

Route53: サイトの独自ドメイン化に使用

ACM: サイトの https 化に使用

S3: 静的ホスティングサービス。書籍画像の保存・管理に使用

Netlify

フロントエンド(create-react-app)のホスティングで利用。

最初はバックエンドに合わせてフロントも AWS ( Amplify Console ) でホスティングしていたのですが、create-react-appはSPAとしてのアプリ開発となることから、metaタグ無いにOGP情報を保持できない = Twitterでページをシェアした時のカード表示を動的に制御できない、という問題が出てきました。

おそらくは AWS でも解決する手段はあると思うのですが、今回は Netlify の Pre-rendering機能を使うことで解決することにしました。この機能を使うことで、 create-react-app であっても、サーバー側で javascript をレンダリングしてからブラウザが解釈できるようになります（あと単純に、無料で利用できるのもメリット）

この問題にあたってから、最近ホットな React フレームワークの Next.js の有り難みが自然と分かるようになってきた( Next.js は SPA/SSG/SSRを選択可能 )のですが、今回はすでに開発を始めていたこともあり、create-react-app + Netlify の構成で最後まで開発しました。

CircleCI

国内ではデファクトスタンダードとされている、Saas型のCI/CDサービスです。今回CircleCIで自動化した処理は、

Rspec

rubocop

eslint&prettier

AWS ECR への Image push

AWS ECS のタスク&サービスの更新

Netlifyにはもともと自動デプロイ機能がついていることから、CircleCIを導入することで、Github上の master ブランチに merge しただけで、本番環境への再デプロイが完了する、という状態に持っていくことができました。

一度ありがたみが分かると、もう手放せないですね( ´ ▽ ` )

3. 学習ロードマップ

さて、いよいよ本題です。ここまでで開発したアプリについて解説をしてきましたが、ここからは、このアプリ開発に至るまでの学習過程をたどっていきます。

第1章でもお伝えした通り、筆者はプログラミング経験自体はあっても、いわゆる「Web系」の知識はゼロからのスタートでした。繰り返しますが、HTMLすら知らなかった状態から、独学ベースで上記技術スタックをアプリに盛り込めるレベルまで到達することができました。

独学ベースでの学習になると、「どの学習教材を選ぶべきか」というところから自分で考える必要があります。いろいろと紆余曲折ありましたが「これは役に立った！」と思うものを厳選し、時系列に沿ってお伝えします。

※下記サービスのWebリンクや、ロゴ画像、ホームページのスクリーンショットについては、事前に各運営者様に使用許可をいただいております。改めまして運営者皆様、利用快諾していただきありがとうございました。

3.1 Progate

皆大好きProgate。今からエンジニアを目指す方は、全員ここから入門して間違い無いでしょう。

URL: https://prog-8.com/

自分は手当たり次第に色々な講座をやってみていましたが、

HTML&CSS

Javascript(ES6)

jQuery

Ruby

Ruby on Rails

次いで

Command line

Git

SQL

辺りを押さえておけば十分だったかと思います。

各講座の序盤のレッスンは無料会員でも受けることができますが、本気でエンジニアを目指すのであれば、有料会員限定のコースも含めて取り組んでいきましょう。

これだけでもそれなりにボリュームはありますが、挫折しにくいよう学習ステップがかなり細かく設定されているので、初心者にとっても易しいつくりになっています。

ただ、Rails講座だけはさすがに難易度が高かったです。。。これは、Progateさんの講座の作り云々ではなく、Webフレームワークという概念が初学者にとって「始めまして」になるので、多少仕方がない部分ではあると思います。

1周目で全体像の把握、2週目以降で詳細理解に努める、というスタンスでよいかと思います。

3.2 Ruby on Railsチュートリアル

皆大好き(?) Rails チュートリアル。

URL: https://railstutorial.jp/

色々賛否ある教材ですが、無料かつ、ここまで体系的に「RailsのWebアプリ開発」を学べる教材は他にないと思います。

本教材の謳っているところでもありますが、「単にRuby, Railsの学習に終始せず、Webアプリ開発の全体像を俯瞰する」ものですので、本教材での知識は、他言語・他フレームワークで開発をする場合でも大いに活きると思います。

確かに、当教材に対する否定的な意見はいくつか見受けられ、

テストフレームワークとして、国内企業でデファクトスタンダードになっているRspecではなく、Railsに標準搭載されているminitestを使用している

採用技術が古くなってきてしまっている

という点がよく指摘されています。

ただ、前者については、株式会社YassLab代表のコチラのYoutube動画の動画でも説明がある通り、「かつて(第２版まで)は Rspec を Rails チュートリアルでも採用していたが、Rspec 自体の学習コストが高いこともあり、それによる脱落者を多く出していた」という背景を受けてのものになります。

また後者については、例えば現在の Rails企業の多くは、Rails単体のアプリケーション(フロントはjQery/bootstrap)ではなく、APIとしてRailsを利用し、フロントはJSフレームワーク(Vue.jsやReact.js)を使うのが一般的になってきています。しかし、Rails初学者が、いきなりAPI開発から始めるのは、理解の階段を飛ばしすぎている、というのも事実でしょう(これについては、同者のコチラのYoutube動画も参考になるかもしれません)

つまり、Rails チュートリアルは「Railsを初めて触る人がなるべく挫折しにくい難易度設定を目指す」ということを念頭に置いた教材であり、最前線の現場で使用されているような本格的なRailsの習得の橋渡しをするようは役割である、と考えることができるかと思います。逆に、これ以上現場に近づけた本格的な内容にしてしまうと、それこそ多くの初学者が挫折してしまうと思います。

したがって、Rails初学者は、今この時代であっても自信を持って当教材に取り組んでよいと思います。少なくとも自分は、この後にも続くRails学習において、ベースとなるような知識をつけることができた、と感じています。

ただ、いくら難易度を落としているとはいってもRails初学者に取ってはかなり難しく、かつ量も膨大であるのは事実です。そのため、Railsチュートリアル完走を一つのマイルストーンとして設定し、内容につまづいたら「ひたすらググる」あるいは「適宜Progateに戻る」という進め方が効率的かと思います。

私も、一度はあまりの量と難易度に挫折してしまったのですが、社会人としてすでに働いており、ある程度お金に余裕があったので、動画版を購入して最後までやり切りました。個人的には、人が解説してくれている形式の方が理解がスムーズで、モチベーションの維持もしやすかったで、お金に余裕のある方にはオススメです。

Railsチュートリアルで身につく知識を整理すると、

バックエンド: Rails(シングルアプリケーション)

フロントエンド: jQuey+bootstrap (Railsの一部として内包)

テスト: minitest

開発環境: AWS cloud9

デプロイ: Heroku

全くの初心者からWebアプリとして求められる一通りの機能を実装し、本番環境へデプロイするところまでできるのは、やはり教材として素晴らしいと思います。

しかし先ほども述べた通り、当教材はあくまでも橋渡しの位置付けです。未経験からの転職という自分自身の立場を鑑みると、Web系企業への転職用PF作成の準備としては、技術面でまだ心許ない、と考えました。

改めて複数企業の採用ページから実際に企業で使用されている技術を確認し、上記の学習知識と比較して整理をすると、

フロントは、Vue.jsやReact.jsといったJavaScriptフレームワークを使用するのが一般的。それに伴い、Railsは単独アプリとしてではなく、APIモードで開発する

テストフレームワークは、minitestではなく、Rspecがデファクトスタンダード

開発環境はPCローカルに構築する(Vagrantで仮想マシンを構築するか、Dockerでコンテナ化するか)

アプリケーションのデプロイは、小規模であれば Heroku を使うこともあるが、企業が提供するような中・大規模なアプリケーションであれば、AWSやGCPなどをよく用いられる

次に習得すべきは、ここの技術領域であることが分かりました(個人的な話ですが、この辺りの時期からエンジニア採用ページに書かれている各技術がスタックが、どういった内容であるかが理解できるようになってきており、成長を実感していました)。

Railsチュートリアルを完走した方は、完走者向けのロードマップ紹介ページもありますので、まずはここを見てみるものよいかと思います。しかし私は、洗い出した上記項目をより体系的に学ぶことができるものがないかと考え、自分なりに色々と教材を探してみた結果、以下のサービスに辿りつきました。

3.3 Take off Rails

URL: https://freelance.cat-algorithm.com/lp/take-off-rails

『あなたを「初心者エンジニア」から「現場で活躍できるエンジニア」まで引き上げます。』というスローガンを掲げた教材とメンターがセットになったサービスで、Rails チュートリアルと実際の企業の間の穴埋めを狙った内容になっています。

基本的にはすでに作成された教材に則っとりながら自分のペースでアプリを開発していくのですが、都度 Slack でメンターさんに質問を投げることができるというのが大きな特徴です。。

最終的な教材のゴールとしてはQiitaのクローンサイトを開発することになります。これの技術スタックは下記の通りです。

バックエンド: Rails APIモード

フロントエンド: Vue.js (ソースコードは作成済みのものを使用。あくまで Rails との繋ぎ込みまでを扱う)

テスト: Rspec(+Factory_bot)

開発環境: ローカル + DB(MySQL) は Docker コンテナを利用

アプリのデプロイ: Heroku

その他: CircleCI による rspec, rubocop の自動化

※ 私の当サイト用のリポジトリ： https://github.com/ddpmntcpbr/qiita_clone

Railsチュートリアル時点での技術スタックと比べると、かなり実務に近い技術が盛り込まれていることが分かるかと思います。

こちら、決して安い金額ではないサービスだと思います(スクール等に比べれば全然安いですが)。ただ、当時欲しいと思っていた知識が一気に身に着けられると考えて、購入を決意しました。

結果、良い買い物だったと思います。自分が学びたい内容がきれいに体系化されていたこともそうですが、何より、教材内容についてメンターさんへ質問ができるのも有意義だと感じました。遅くとも24時間以内にはレスポンスが返ってくるのもありがたく、「料金分を回収してやるぞ！」という気持ちで、たくさん質問させてもらいました笑

本教材では、上記技術の学習だけでなく、

Git commit の適切な粒度や、コミットメッセージの書き方

Github での PR の出し方や、コードレビューの流れ

Slack でのやり取り(意図が伝わりやすい質問の仕方など)

といった、「独学ではなかなか身につかない」けど「チーム開発では必須になる」ような周辺知識について学べた点も、非常に有用だったと思います。Railsチュートリアルの内容がおおよそ理解できていれば前提知識としては十分な難易度で、大きく挫折をすることがなかった点もプラスです。

さて、ここまでで、Railsに関しては、比較的モダンな開発手法に触れることができました。

しかし、当教材ではあくまでも Rails の開発に的を絞ったものであり、フロントエンドは既存のソースコードを流用する形での学習でした。この教材の内容を自身の転職用PFに組み込むためには、フロントエンド側についても自身で開発する知識が必要と考えました。

フロントエンドフレームワークの選定について、第２章でもお伝えしたとおり、「Reactの方がなんとなくよさそうかなー」と考えていたところ、次の教材を見つけたことをきっかけに、正式に React の学習を始めることにしました。

3.4 【とらゼミ】トラハックのエンジニア学習講座

現役の React エンジニアであるトラハックさん ( @torahack_ )が、Youtube上で公開している講座で、Reactについて基礎の基礎から学ぶことができます。

動画チャンネルURL: https://www.youtube.com/user/1492tiger

こちらの教材の特長は、

Reactの基礎の基礎から体系的に学べる( Progate の JavaScript 講座完了が受講目安)

動画によるハンズオン形式

教材範囲にモダンなフロントエンドの開発手法を含む( Redux 等)

動画のほぼ全てがYoutube上でなぜか無料公開されている

特に最後については完全にバグとしか思えない点で、Udemyなどで有料販売されていても動画講座と比べても遜色ないクオリティだと思います。

動画教材にありがちな「準備した原稿丸読み」のような堅い口調ではなく、フランクな若手予備校教師の授業(?)のような語り口のため、硬い喋りが苦手な人にもお勧めできます。私は復習のために、一度見た動画を耳だけで聞き返したりして、記憶の定着を図りました。

講座はいくつかのシリーズに分かれており、私が視聴をしたのは、

1.『日本一わかりやすいReact入門』シリーズ
2. 『日本一わかりやすいReact入門【実践編】』シリーズ
3. 『日本一わかりやすいReact-Redux入門』シリーズ

の3シリーズです。

最終的な成果物の技術スタックは、

create-react-app

Redux & redux-thunk

Material-UI

Firebase： Google が提供する mBaaS。バックエンド＋インフラを手軽にセットアップできる

です。

※ 私のGithubリポジトリ: https://github.com/ddpmntcpbr/react-ec-app

こちらの動画については、学習備忘録記事をQiitaに投稿しております。よろしければこちらもご参考下さい。

参考ページ: 『日本一わかりやすいReact入門【実践編】#1~5 学習備忘録』

本学習講座を全て受講するためには、有料コミュニティ『とらゼミ』への加入が必要になりますが、筆者は無料公開範囲の動画で必要な知識は十分に身に付いたと感じたため、加入はしておりません。（代わりの記事として書くことで、宣伝として少しでもお役に立てればと思っています笑）

さて、ここまででフロント側も自力で開発ができる基礎が身に付きました。これくらいの時期に並行してアプリのコンセプトが決定していましたので、いよいよポートフォリオ作成に取り掛かり始めました。

しかし、開発を始めるといくつも壁が出てきます。基本的にはググりながらの解決をしていきましたが、どうしても解決できないエラーにもぶち当たりました。特に、

ReactとRailsの繋ぎ合わせ

AWSでのアプリの公開方法

その他インフラ知識全般

あたりが、個人的な難所でした。その過程で頼らせてもらったのが、次のメンターサービスです。

3.5 TechTrain

有名企業のエンジニアから実務を学べるオンラインコミュニティ です。

URL: https://techbowl.co.jp/techtrain

特長を列挙すると、

現役エンジニアであるメンターさんと、1 on 1でのオンライン面談が可能

メンターの方々の技術領域は多種多様

全てのメンターと面談が可能で、技術トピックに応じて切り替えることが可能

面談はこちらからのタイミングで入れることができる

なぜか全て無料で利用できる

はっきり言います。これだけのことができて完全無料なのはどう考えてもバグです。これからエンジニア就職を目指しているU30の学生・社会人は、全員登録した方がいいレベルです

TechTrain の中ではいくつかの Mission が設けられており、それをメンターと一緒に取り組んでいくことで知識を習得していく、ということが可能です。 Mission は実際のIT企業とのコラボで作成されており、中には「Missionをクリアできた人は一次面接をスキップできる」のような特典もついていたりします。

ただ私は Misson には取り組まず、あくまでの個人開発のサポートとして利用させてもらっていました。基本的には自身の既存知識とググり力でPF作成を進めつつ、どうしても解決できない課題が出てきたときにピンポイントで面談予約を入れる、というイメージで、個々人の利用したい形式/ペースで利用できる点も大変ありがたかったです。

異なる技術領域を持ったエンジニアの方々全員と面談をするが可能なため、Rails, React, AWSそれぞれで、別のメンターの方に質問をさせてもらっていました。

特に自力での解決が難しかったのがAWS周りの本番環境構築で、本サービス無しでは乗り越えられなかったと思います。

最終的には、自身のググり力 + TechTrain で都度メンターを利用、を繰り返すことで、無事アプリを完成させることができました!

3.6 番外編

上記以外で役に立ったものについて、ざっくばらんに紹介します。

Udemy 『Git：はじめてのGitとGitHub』

無料で Git の基礎を学べる講座です。「Gitよう分からん！」って人は、まずこれから触れてみましょう

 『キタミ式イラストIT塾基本情報技術者』

基本情報処理の定番本です。コンピューターサイエンス領域の基礎知識が体系的に学べます。イラストが豊富であり、文章表現も柔らかいので初心者にも優しいです。資格自体の取る/取らないに関わらず一読をオススメします。

『米国AI開発者がゼロから教えるDocker講座』

Dockerについて一から学べる動画教材です。作者様はデータサイエンス領域の方ですが、Webアプリ開発を目的とした人であっても問題ありません（実際に、講座後半では、docker-composeを利用したRailsコンテナの構築まで扱っています）

非常にボリューミーな内容にも関わらず、Udemy講座の中ではかなり良心的な価格設定です。

『【AWS 入門】EC2とDockerでHello Worldしよう』

AWSについて何にも分からない状態から、「nginxだけのシンプルなコンテナアプリを動かす」ところまで、ハンズオン形式で学習ができます。

AWSのとっつきにくさは、「①インフラの概念が分からない」「②専門用語が分からない」に集約されると思います。まずは手を動かしながら、AWSでアプリをデプロイ流れを全体像で掴むことができます。

3.7 アプリの改善点

一通りアプリを完成させてみて、初めて見えてくる改善点が多くありましたので、合わせて列挙します。

AWSサーバー代高すぎ！！！

スケーラビリティの高い中・大規模向けインフラ構成になっているため、サーバー代がめっちゃ高い笑

長く公開するためには、どこかのタイミングで無料サーバーへ移管する必要があるかなと思います。Heroku の無料枠で上手にやりくりできれば、解決できるかもしれないです。

フロントエンドは Next.js + Typescriptで実装したい

Next.js はレンダリングのタイミングを制御できるので、OGP情報の保持が簡単に実現できます。

また、それ以外でも、

ルーティング設定が簡単

パフォーマンスをよくするような機能も豊富

Typescriptの導入が用意

というメリットもあり、とても気になっているフレームワークです。次、全く同じアプリを開発するとするのであれば、絶対に採用したい技術です。

デザインがあやしい気がする・・・？

アプリを開発して気づいたのは、アプリにおけるデザインの重要性です。

これを思った理由は単純で、開発途中で「なんか自分のアプリ、イケてなくない？」と感じたからです笑

Webアプリにおけるデザインは、単なるお洒落さに関するものだけでは決してありません。デザインは、ユーザーにとって必要な情報を適切に配置することであり、ユーザーの価値提供のための最前線領域です。

ユーザー側から価値提供の流れ(バリューチェーンと表現するのでしょうか)をざっっっくり並べると、

ユーザー -> UI/UXデザイン -> フロントエンド -> バックエンド -> インフラ

のようになっていると思っています。

「エンジニアになろう！」と意気込んでから、後ろ3つについてはそこそこ勉強してきました。しかしデザイン領域については、開発初期は完全素人の状態で、途中までは勘でやっていました。。。

一応、付け焼き刃程度ではありますが、デザインの名著である『ノンデザイナーズ・デザインブック』に目を通し、途中からは意識できる範囲ではデザインのことを意識して、フロントを実装しました。

うまく取り込めているかは分かりませんが、少なくとも「デザインはセンスではなく論理」であることが学べただけでも、よい勉強になりました。こちらの書籍も、転職用PF作成者にオススメしておきます。

4. さいごに

以上、大変長い記事でしたが、最後まで読んでいただきありがとうございました。タイトルでは「学習ロードマップ」と銘打っておきながら、私自身の思考プロセスや価値観についても多く書かせてもらいました。

「エンジニアになりたい！」と思い立ってから、学習自体はほぼ一人で淡々と進めてきました。しかし、ほぼ独学でここまで学習を進めることができたのは、多くの先輩エンジニアの方々が様々な情報をインターネットに投稿し、それをオープンに取得できる環境にあったからだと思っております。

それであれば、次は自分自身が、他の駆け出しエンジニアの方々の助けになるような情報を発信できれば、と思い、この記事を書くこととしました。参考になったという方がいらっしゃったら幸いです。

是非LGTM、ストック、twitterでのシェアお願いします！また、私自身もtwitterをやっておりますので、気軽にフォローしてもらえるとうれしいです(^^)

よろしくお願いします！

Twitter: https://twitter.com/ddpmntcpbr
Github: https://github.com/ddpmntcpbr/rails_react_docker

5. おまけ画像素材等紹介(※2021/3/11追記)

アプリの本筋には関係ありませんが、アプリの本格感を演出するために利用したサイトやアプリを紹介しておきます。

6.1 ロゴ画像

『Hatchful』という自動ロゴジェネレーターサイトを利用しました。誰でもカンタンに、お洒落でそれっぽいロゴを作ることができます（無料です）

ここでロゴの雛形を作り、mac標準搭載の『プレビュー』アプリでテキストの追加等カンタンな画像編集を加えました。

6.2 いい感じの画像たち

下記サイトから利用しております。ほどよいユルさが気に入りました

6.3 3分アプリ紹介動画の作成

『QuickTimePlayer』で撮影し、『iMovie』で動画編集をしました。いずれもmac標準搭載のアプリのため、無料です。

iMovieで字幕を入れる技術は、下記のYoutube動画が参考になりました。

BGMは下記サイトのフリー音源を利用させていただきました。

6.4 インフラ構成図

『draw.io』を利用しました。使い方については、触っていればなんとなく分かるかと思いますが、下記にも目を通してよくとよいかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T00:26:07+09:00

Aleph.jsでDenoを使ったReact開発ができるだと！？

はじめに

何気に今年始めての投稿になります。今回は前々から気になっていたDenoとそのReactフレームワークであるAleph.jsを少し触って、その雰囲気を確かめてみよう！といった内容の記事です。特に内容はないですが、Denoを使ったReact開発環境構築がNext.jsの感覚で簡単にできてしまいました。

Denoって？

一言でまとめるとRust製のJavaScript・TypeScriptランタイムです。Node.jsと違って以下のような特徴があります。

デフォルトではファイル・ネットワークへのアクセスが不可（明示的にEnableを指定する必要がある）

TypeScriptコンパイラを内包している（tsc等の導入が不要）

Aleph.jsって？

Aleph.js（あれふ？読み方わかんないです。。。）はDenoのためのReactフレームワークです。Next.jsに影響を受けてつくられたフレームワークとのことで、SSRやSSG等がサポートされています。

とりあえず触ってみる

Aleph.jsの始め方はGet Startedを見ればだいたいわかります。CLIツール周りもNext.jsとほとんど同じ感覚で使えそうです。現状のところ推奨されている開発環境は以下です。

Deno v1.7以降

denoのvscode拡張を使用

そして現時点（2021/02/20）ではv0.3.0のAlphaバージョンが最新のようなので、それをインストールします。
deno install -A -f -n aleph https://deno.land/x/aleph@v0.3.0-alpha.1/cli.ts
ちなみに、このバージョンより古いものをインストールするとコンパイル時にエラーを起こす可能性があります（私の方では古いドキュメントを参考にしてv2.6をインストールしたところ、初期のサンプルコードでコンパイルエラーが起こりました）。

これでalephというCLIツールが使えるようになります。基本的にはNext.jsと似たような使い方です。

プロジェクトの作成
aleph init hello
developmentモードでの実行
aleph dev
prodモードでの実行
aleph prod
静的サイト（SSG）のビルド
aleph build
サンプルコードを見てみる

aleph initでプロジェクトを作成するとサンプルコードが実装された状態で以下のような構成のプロジェクトが作成されます。
.
├── api
│   └── counter
│       ├── [action].ts
│       └── index.ts
├── app.tsx
├── components
│   └── logo.tsx
├── import_map.json
├── lib
│   └── useCounter.ts
├── pages
│   └── index.tsx
├── public
│   └── logo.svg
└── style
    └── index.css
基本的にはNext.jsと同じような内容になっていますが、Denoっぽい特徴をあげるとimport_map.jsonというものがあります。これはDenoのパッケージ管理ファイルとなっています。
Aleph.jsのデフォルトのサンプルコード（その他のサンプルコードについてはexamplesを参照）はカウンターアプリとなっていて、+と-で数を足したり減らしたりするような内容となっています。
カウンター機能の実装はlib/useCounter.tsの中でuseCallbackを使って実装しているようです。
const increase = useCallback(() => {
  setCount(n => n + 1)
  fetch('/api/counter/increase').catch(e => console.error(e))
}, [])
const decrease = useCallback(() => {
  setCount(n => n - 1)
  fetch('/api/counter/decrease').catch(e => console.error(e))
}, [])
この中でfetch('/api/counter/xxxx')を実行している箇所があります。これはapi/counter/index.tsとapi/counter/[action].tsで定義したhandlerを実行させるために内部でAPIを叩いている部分となります。ディレクトリ構成がそのままAPIのパスにマッピングされるのは、Next.jsとほとんど同じですね。
APIの中ではglobalThisを使ってカウンターの値を保存しています。useCallbackの中でもカウンターの値のインクリメント・デクリメントを行っているのは、APIとの同期を再レンダリングが走るとき(useEffect内部)でのみ行っているからですね。
useEffect(() => {
  fetch('/api/counter').then(resp => resp.json().catch(() => ({})))
    .then(({ count }) => {
      if (typeof count === 'number' && !Number.isNaN(count)) {
        setCount(count)
      }
    })
    .catch(e => console.error(e))
    .finally(() => {
      setIsSyncing(false)
    })
}, [])
Next.js同様、Aleph.jsでもウェブページのレンダリングのためにWEBサーバーを立てることになります。なのでWEBサーバーを使って内部にAPIサーバーを立てることで、データのやり取りをAleph.js内で完結させることができるわけですね。まあ、個人的にはAPIサーバーは別で立てて実装したいと思う派なんですが。。。
あとはpages/index.tsxでページが実装されていて、ここもほとんどNext.jsと雰囲気は同じですね（唯一Deno独自っぽくなっているのがuseDenoを使っているところ？）。これもpages/blog/index.tsxが/blogとなるようにディレクトリがそのままパスにマッピングされる形となっているようです（詳しくはRoutingを参照）。

さいごに

とりあえず今回はAleph.jsで初期に構築されるサンプルコードを見て、Aleph.jsを使った実装の雰囲気を見てみるだけの内容となりました。
実装自体は特にまだできていないので、また時間があれば遊んでみたいと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T00:10:59+09:00

gatsby + wordpress 日本語での投稿に対応する

背景

gatsbyは素晴らしいですね。
簡単に静的サイトが作れて、かつReact.jsをガリガリ書けばカスタマイズ性も抜群。

欠点としてはworedpressのように記事を管理する機能(CMS)がないことです。

それを補う方法としてgatsbyにはプラグインとしてgatsby-source-wordpressが用意されており、このプラグインはwordpress APIを使って既存のwordpressのサイトからAPI経由で記事を持ってくることができます。

実際に使う時はgatsby-theme-wordpress-mdxとともに使いうと、一瞬で静的サイトを作ることができます(詳しい作り方は別に投稿します)。

課題

大変便利なgatsby-theme-wordpress-mdxですが、欠点としてwordpress側のURLに日本語が含まれている場合、下のようなエラーが出てしまい使えません。

どうやらURLエンコーディングに対応できていないようです。

解決策

クライアント側での解決策をいろいろ探したのですが、どうすることもできないようなのでwordpress側で対応します。

URLに日本語が含まれなければ良いのです。

普通にwordpressを使っている場合、wordpressの記事のURL末尾に自動的に付与される"slug"と呼ばれる部分が日本語になって今います。

http://[ドメイン]/2021/02/20/[slugはこの部分]/

そこで、wordpressのfunction.phpを弄ってslug部分を日本語からpost-[id]に変更します。
function auto_post_slug( $slug, $post_ID, $post_status, $post_type ) {
    if ( preg_match( '/(%[0-9a-f]{2})+/', $slug ) ) {
        $slug = utf8_uri_encode( $post_type ) . '-' . $post_ID;
    }
    return $slug;
}
add_filter('wp_unique_post_slug', 'auto_post_slug', 10, 4  );
すると、urlから日本語がなくなるのでクライアント側で問題なく投稿記事が見れるはずです。

　 Tweet
Qiitaで続きを読む

投稿日：2021-02-21T00:01:05+09:00

reactプロジェクトを作成する時のnpm installするパッケージ

プロジェクトディレクトリを作成
プロジェクトディレクトリ作成
mkdir project
npm init

npm initはnpmを使用して対象プロジェクトのパッケージ管理をするために必要なpackage.jsonを作成するためのコマンド。
先ほど作成したプロジェクトディレクトリに移動して実行する。
cd project
npm init
実行すると、下記の項目について何を設定するか聞かれる。
何も入力せずEnterを押せばデフォルトの項目が設定される。
※全てデフォルトで良いのであればnpm init -yで実行することがおすすめ。-yはyesの意味。
もし、入力を間違えたとしても後でpackage.jsonを修正すれば良い。

項目意味デフォルト値

name プロジェクト名プロジェクトディレクトリ名

version プロジェクトバージョン 1.0.0

description パッケージの説明空文字

main プログラムへの主要なエントリポイント index.js

script テスト用のコマンド "test": "echo \"Error: no test specified\" && exit 1"

keywords キーワード
※プロジェクトを公開した時に検索の手助けとなるワードを設定空配列

author 著者空文字

license プロジェクトのライセンス ISC

ちなみにISCライセンスは、簡単に言ってしまえば「自由に使っていいよ。ただし、このプロジェクトのコピーライトは記載してね」というライセンス。原文はこちら。

コマンド実行後、下記のようなpackage.jsonが作成される。
{
  "name": "project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
reactプロジェクトのためのパッケージインストール

パッケージはローカルインストールで行う。
npm install --save-dev パッケージ名
--save-devを指定すると、package.jsonのdevDependenciesに追記してくれる。
本番環境で環境構築や、他のメンバにプロジェクトを手伝ってもらうときに簡単に環境構築できるように--save-devは必ず指定する。

あとは、下記リストのパッケージをインストールすればとりあえずreactは動く。
reduxとか使用したければ別途インストール。

パッケージ名役割

@babel/core Babel本体

@babel/preset-env サポートされている環境に基づいて必要なBabelプラグインを自動で決定する

babel-loader webpackでコードを変換するためにBabelを使用するよう指示する

babel-plugin-add-module-exports Node.jsの変換時に使用する

@babel/preset-react 全てのReactプラグイン用のBabelプリセット

babel-plugin-react-html-attrs JSX内でclassNameではなくclassを使えるようにする

babel-plugin-transform-class-properties クラス外でクラスプロパティが定義された時に正常にBabelで変換できるようにする

react react本体

react-dom reactでDOMを操作する

react-router-dom React Routerのコアルーティング機能を提供する

webpack webpack本体

webpack-cli webpackコマンドを使用できるようにする

webpack-dev-server webpackを用いたフロントエンド開発のときに利用できる開発用のwebサーバー

axios 非同期でHTTP通信を行う

参考サイト

@babel/preset-env (Babel 7)をハンズオンでちゃんと理解する
 react-routerとreact-router-domの違い
 Babelの設定を見直すための逆引きガイド
 npm install の --save-dev って何？
Babeljs-babel-plugins
BabelJS-Babelプラグイン

項目	意味	デフォルト値
name	プロジェクト名	プロジェクトディレクトリ名
version	プロジェクトバージョン	1.0.0
description	パッケージの説明	空文字
main	プログラムへの主要なエントリポイント	index.js
script	テスト用のコマンド	"test": "echo \"Error: no test specified\" && exit 1"
keywords	キーワード ※プロジェクトを公開した時に検索の手助けとなるワードを設定	空配列
author	著者	空文字
license	プロジェクトのライセンス	ISC

パッケージ名	役割
@babel/core	Babel本体
@babel/preset-env	サポートされている環境に基づいて必要なBabelプラグインを自動で決定する
babel-loader	webpackでコードを変換するためにBabelを使用するよう指示する
babel-plugin-add-module-exports	Node.jsの変換時に使用する
@babel/preset-react	全てのReactプラグイン用のBabelプリセット
babel-plugin-react-html-attrs	JSX内で`className`ではなく`class`を使えるようにする
babel-plugin-transform-class-properties	クラス外でクラスプロパティが定義された時に正常にBabelで変換できるようにする
react	react本体
react-dom	reactでDOMを操作する
react-router-dom	React Routerのコアルーティング機能を提供する
webpack	webpack本体
webpack-cli	`webpack`コマンドを使用できるようにする
webpack-dev-server	webpackを用いたフロントエンド開発のときに利用できる開発用のwebサーバー
axios	非同期でHTTP通信を行う

　 Tweet
Qiitaで続きを読む

20210221のReactに関する記事は14件です。

JavaScriptでcsvダウンロードを実装する方法

はじめに

実装

ISR(Incremental Static Regeneration)とは？

ISR(Incremental Static Regeneration)とは？

メリットって？

VercelにDeployしてみる

ISRのpagesコンポーネントを作成

VercelにDeployしてみる

参考

React+Material-uiでページ内リンクを実現する

はじめに

ページ内リンクの基本

Reactでの書き方

最後に

reactで条件にあった時に特定のclassを付与する書き方

書き方

共通のクラス名を付与しない場合

どちらにも共通のクラス名を付与した上で、+αで条件によってクラス名を付与したい場合

参考記事

VSCode + TypeScript + React で開発を行う人のための ESLint + Prettier の環境構築 2021

はじめに

ESLint の導入

1. ESLint 本体について

2. 拡張機能の追加

3. ESLint の設定

Prettier の導入

1. Prettier のインストール

2. 拡張機能の追加

3. .prettierrc の作成・記述

ESLint と Prettier の連携

1. VSCode の設定

2. eslint-config-prettier のインストール・適用

3. 動作確認

参考資料

VSCode + TypeScript + React で開発を行うための ESLint + Prettier の環境構築 2021

はじめに

ESLint の導入

1. ESLint 本体について

2. 拡張機能の追加

3. ESLint の設定

Prettier の導入

1. Prettier のインストール

2. 拡張機能の追加

3. .prettierrc の作成・記述

ESLint と Prettier の連携

1. VSCode の設定

2. eslint-config-prettier のインストール・適用

3. 動作確認

参考資料

Next.js, tailwindcssでウェブアプリを作りvercelでhostingする手順

手順

DjangoとReact redux TypeScriptを使ってオリジナルアプリを作ってみました（TwitterAPI）その1

まず私について

オリジナルアプリ概要

機能詳細

使用言語、ライブラリ

開発に至った経緯

アプリ構造

モデル

イメージポスト、Imagesモデルについての考察

settings

ここまでの感想

【未経験】独学＋メンターでここまで出来た！Web知識ゼロからモダンな技術アプリ開発までに利用した5つのサービス【Rails / React / AWS / Docker / CircleCI】

0. はじめに

アプリ名： 積読解消アプリ 「Yomukatsu!」

【3分動画】Yomukatsu 字幕解説

使用技術

インフラ構成

機能一覧

ユーザー利用機能

非ユーザー利用機能

この記事について

1. 自己紹介

1.1 筆者スペック

2. 開発アプリ解説

2.1 コンセプト方針

(a) 実際の企業が採用しているようなモダンな技術を採用する

(b) 具体的な解決課題を明確にする

3. `.prettierrc` の作成・記述

2. `eslint-config-prettier` のインストール・適用

3. `.prettierrc` の作成・記述

2. `eslint-config-prettier` のインストール・適用

アプリ名：積読解消アプリ「Yomukatsu!」

`Docker/docker-compose`

`AWS(Amazon Web Service)`

`Netlify`

フロントエンドは `Next.js` + `Typescript`で実装したい

アプリ名：積読解消アプリ「Yomukatsu!」

`Docker/docker-compose`

`AWS(Amazon Web Service)`

`Netlify`