【Git】ローカルで作成したリポジトリを GitHub に Push する【GitHub】

はじめに

開発で Git を使用する場合、既に GitHub などにあるリモートリポジトリをローカルにクローンするケースがほとんどではないでしょうか。

かくいう僕もその一人で、プロジェクトに参画したときには既にリモートリポジトリが存在し、クローンしてブランチを作成して開発を始める経験しかありませんでした。

しかし、例えば個人開発などでは、とりあえずローカルで開発を始めてみて、良さそうだったら GitHub でリポジトリを管理するというケースもあると思います。

もちろん先に GitHub にリポジトリを作って、それをクローンしてイチから開発を始める方法もありますが、継続して開発するかどうか分からない段階でリモートリポジトリを作るのはちょっと抵抗があります。

というわけで、今回はローカルで作成した Git リポジトリを GitHub で管理し始める (初めて Push するまでの) 手順についてまとめました。

動作環境

OS	Version
Windows 10 Pro	1909

Application	Version
PowerShell	5.1.18362.752
Git	2.26.0

Hosting Service
GitHub

前提

• ローカルマシンに Git をインストール済み
• ローカルマシンに Git リポジトリ (ローカルリポジトリ) を作成済み
• ローカルの Git リポジトリには master ブランチが存在する
• GitHub にアカウントを作成済み
• GitHub への SSH 接続が可能 (SSH 接続の設定済み)

Git のインストールや GitHub への SSH 接続については、別記事を参照ください。

ai-can-fly.hateblo.jp

ai-can-fly.hateblo.jp

ai-can-fly.hateblo.jp

リモートリポジトリ (GitHub)

今回はリモートリポジトリを GitHub に作成します。

Git リポジトリ作成

GitHub に新しいリポジトリを作成します。

リポジトリの作成については、 GitHub ヘルプに詳細な手順が記載されているので、そちらをご覧ください。

help.github.com

リポジトリ名はローカルリポジトリの名前と同じにする必要はありませんが、揃えておいた方が分かりやすいと思います。

作成時の注意

リポジトリ作成画面に Skip this step if you’re importing an existing repository. とある通り、既に存在する Git リポジトリ をインポート (ローカルからの Push 含む) する場合は、赤枠内の各項目はいずれも作成しません。

• Initialize this repository with a README
  • ここにチェックを入れると README.md が作成される
• Add .gitignore
  • None 以外を選択した場合、 .gitignore ファイルが作成される
• Add a license
  • None 以外を選択した場合、 LICENSE ファイルが作成される

一つでも作成すると、リポジトリ作成と同時に master ブランチが作成されてしまい、ローカルにある master ブランチとのマージが難しくなります。 (マージができないわけではありません)

リモート URL を確認

作成したリポジトリのページに記載されているリモート URL を確認します。

上の画像はデータ転送プロトコルが SSH ですが、 HTTPS も使用できます。

ローカルリポジトリ

リモートリポジトリの作成を行ったら、次にローカルの Git リポジトリ内で以下の作業を行います。

リモートリポジトリを追加

ローカルリポジトリに GitHub で作成したリモートリポジトリを追加します。

git remote add origin git@github.com:hrgm/about-hrgm.git

リモートリポジトリの追加については、こちらも GitHub ヘルプに詳細が記載されています。

help.github.com

git remote add コマンド

git remote add [remote_name] [remote_url]

Argument	Description
[remote_name]	リモートリポジトリ名 (一般的には origin がよくつかわれる)
[github_remote_url]	リモート URL (GitHub の場合は SSH か HTTPS の URL を使用する)

ローカルの Git の Config へ remote_name という名前で リモート URL (remote_url) を追加する。

リモートリポジトリへ Push

追加したリモートリポジトリへ、ローカルリポジトリのブランチを Push します。

git push origin master

Push 後に GitHub のリポジトリを見ると、ブランチが登録されているのが確認できます。

リモートリポジトリへの Push についても、 GitHub ヘルプに詳しい記載があります。

help.github.com

リモートリポジトリへ Push を行うと、ローカルリポジトリにリモート追跡ブランチ (origin/[remote_branch_name]) が作成されます。

git push コマンド

git push [remote_name] [local_branch_name]:[remote_branch_name]

Argument	Description
[remote_name]	リモートリポジトリ名
[local_branch_name]	ローカルブランチ名
[remote_branch_name]	リモートブランチ名 (省略した場合、ローカルブランチ名と同じになる)

リモートリポジトリ (remote_name) のリモートブランチ (remote_branch_name) へ、ローカルブランチ (local_branch_name) を Push する。

上流ブランチの設定

リモートリポジトリへ Push しただけでは、リモート追跡ブランチが作成されても、ローカルリポジトリのブランチに上流ブランチとしては設定されません。

以下のコマンドで上流ブランチを設定する必要があります。

git branch master --set-upstream-to=origin/master

上流ブランチを設定することで、 git push, git merge, git pull を行う際の引数 (リモートリポジトリやブランチ名の指定) を省略できるようになります。

git branch コマンド (--set-upstream-to オプション)

git branch [local_branch_name] --set-upstream-to=[remote_name]/[remote_branch_name]

Argument	Description
[local_branch_name]	ローカルブランチ名
[remote_name]	リモートリポジトリ名
[remote_branch_name]	リモートブランチ名

ローカルブランチ (local_branch_name) に、リモート追跡ブランチ (remote_name/remote_branch_name) を上流ブランチとして設定する。

Push と上流ブランチの設定を同時に行う

上記では説明のために Push と上流ブランチの設定を順に分けて行いましたが、 git push コマンドの -u オプションを使用すると、ローカルブランチの Push を行うと同時に、リモート追跡ブランチをローカルブランチの上流ブランチとして設定することができます。

git push -u origin master

GitHub で新規に空のリポジトリを作成すると、リポジトリのページに簡単な説明とこのコマンドが記載されています。

Git に慣れてきたら、ローカルリポジトリ発のブランチをリモートリポジトリに Push する際は、こちらのコマンドを使用することが多くなると思います。

おわりに

今回は GitHub を使用したリモートリポジトリへの Push を説明しましたが、基本的な考え方は GitLab などの他の Git ホスティングサービスであっても変わりません。

Subversion と違って Git は初期の学習ハードルがやや高いところがありますが、この辺りは使っていくうちにどんどん理解が進んでいくはずなので、めげずに使い続ければ、いつか目の前がパァーっと開ける日がやってきます。

まぁ、僕は半年くらいかかりましたけどねー！

【Oracle Database 19c】データベース (CDB と PDB) への接続と各種操作【SQL*Plus】

はじめに

自宅で Oracle Database 19c を使用していて、 SQL*Plus でのデータベース接続や起動と停止方法をいつも忘れてググっているので、せっかくなのでまとめて記事にしてみました。

EM Express (Oracle Enterprise Manager Database Express) を使用すれば GUI で各種操作を行うことができますが、今回は CLI (SQL*Plus) での操作に限定してまとめています。

動作環境

OS	Version
Windows 10 Pro	1909

Application	Version
PowerShell	5.1.18362.752

Database	Version
Oracle Database 19c	19.3.0

SQL*Plus の起動

sqlplus /nolog

データベースには接続せず、 SQL*Plus のみを起動します。

SQLPlus の起動と同時にデータベースへ接続することも可能ですが、 CLI のコマンド履歴にユーザとパスワードが残る可能性があるので、セキュリティの観点から言えば、 SQLPlus 起動後に CONNECT コマンドでデータベース接続することをお勧めします。

データベース接続

SQL*Plus 起動後、 CONNECT コマンドでデータベースへ接続します。

ローカル接続

-- ユーザ権限
CONNECT [username]/[password]

-- SYSDBA 権限
CONNECT [username]/[password] AS SYSDBA

ローカル接続では、 OS の環境変数 (ORACLE_SID) に登録されているデータベースに接続されます。

簡易接続ネーミング・メソッド

-- ユーザ権限
CONNECT [username]/[password]@[host]:[port]/[service_name]

-- SYSDBA 権限
CONNECT [username]/[password]@[host]:[port]/[service_name] AS SYSDBA

サービス名 (service_name) には、初期化パラメータ・ファイルの SERVICE_NAMES (= DB_UNIQUE_NAME.DB_DOMAIN) を入力します。

PDB に接続する場合のサービス名 (service_name) は、 pdb_name.DB_DOMAIN になります。

ローカル・ネーミング・メソッド

-- ユーザ権限
CONNECT [username]/[password]@[net_service_name]

-- SYSDBA 権限
CONNECT [username]/[password]@[net_service_name] AS SYSDBA

ローカル・ネーミング・メソッドを使用する場合、ネットワーク・サービス名 (net_service_name) を tnsnames.ora ファイルに追加する必要があります。

データベース起動

CDB

CDB の起動は SYSDBA または SYSOPER 権限を持つユーザで行う必要があります。

STARTUP [OPEN [db_name] | MOUNT [db_name] | NOMOUNT]

STARTUP と STARTUP MOUNT コマンドで [db_name] を省略した場合、初期化パラメータ・ファイルの DB_NAME のデータベース名が使用されます。

• OPNE
  • Oracle インスタンスを起動し、データベースをマウントして、オープンする
  • オンライン REDO ログ・ファイル、およびデータファイルが開かれ、データへのアクセスが可能になる
• MOUNT
  • Oracle インスタンスを起動し、データベースをマウントするが、オープンはしない
  • Oracle インスタンスによってデータベースの制御ファイルが開かれるが、データファイルは開かない
• NOMOUNT
  • Oracle インスタンスのみ起動し、データベースはマウントしない
  • 初期化パラメータ・ファイルを読み込み Oracle インスタンスを起動するが、制御ファイルは開かない

PDB

PDB の起動は SYSDBA 、 SYSOPER 、 SYSBACKUP 、 SYSDG 権限のいずれかを持つユーザが、 CDB に接続した状態で行う必要があります。

ALTER PLUGGABLE DATABASE [ALL | [pdb_name]] OPEN [READ WRITE | READ ONLY];

-- または

STARTUP PLUGGABLE DATABASE [pdb_name] OPEN [READ WRITE | READ ONLY]

• READ WRITE
  • 読取り/書込みモードで PDB をオープンする
• READ ONRY
  • 読取り専用モードで PDB をオープンする

オープン・モードを省略した場合は、 READ WRITE が指定されます。

STARTUP PLUGGABLE DATABASE コマンドは、単一の PDB をオープンすることができます。

PDB の自動起動 (CDB 再起動時の PDB の オープン・モード の保持)

ALTER PLUGGABLE DATABASE [ALL | [pdb_name]] SAVE STATE;

通常、 CDB 再起動 (通常起動) 時の PDB の OPEN_MODE (オープン・モード) は MOUNTED (マウント・モード) ですが、 OPEN_MODE を保持させると、次回 CDB 起動時の PDB の OPEN_MODE を CDB 再起動前と同じ状態にすることができます。

つまり、 PDB の OPEN_MODE が READ WRITE (読取り/書込みモード) で上記 SQL を実行すると、次回 CDB 起動時も PDB の OPEN_MODE は READ WRITE となり、 CDB の起動の度に PDB をオープンする必要が無くなります。

ちなみに、オープン・モードの保持をやめる場合は、 SAVE STATE ではなく DISCARD STATE を指定します。

データベース停止

CDB

CDB の停止は SYSDBA または SYSOPER 権限を持つユーザで行う必要があります。

SHUTDOWN [NORMAL | IMMEDIATE | TRANSACTIONAL | ABORT]

• NORMAL (通常停止)
  • データベースへの新規接続はできないが、接続中の全ユーザーがセッションを終了するまで待機する
• IMMEDIATE (即時停止)
  • アクティブな全トランザクションをロールバックし、接続中の全ユーザのセッションを切断してデータベースを停止する
• TRANSACTIONAL
  • アクティブなトランザクションすべてが完了後、接続中の全ユーザのセッションを切断してデータベースを停止する
• 'ABORT' (緊急停止)
  • アクティブなトランザクションのロールバックを行わず、接続中の全ユーザのセッションを接続してデータベースを停止する
  • 次回のデータベース起動時にインスタンス・リカバリが必要になるため、通常は使用しない

PDB

PDB の停止は、マウント・モードへのオープン・モードの変更を意味します。

ALTER PLUGGABLE DATABASE [ALL | [pdb_name]] CLOSE [IMMEDIATE | ABORT];

IMMEDIATE または ABORT を指定しない場合、通常停止 (NORMAL) となります。

停止モードの詳細は、 CDB の SHUTDOWN コマンドでの停止と同様です。

おわりに

今回は「Oracle Database に接続して CDB や PDB を起動・停止する」という簡単な操作についてまとめました。

記事をまとめる中で、なるべく正確な情報を記載するため Oracle 公式ドキュメントを読みましたが、同じ結果が得られる別の方法や細かいオプションなど、取り上げていない内容が沢山あります。

ORACLE MASTER などの資格を取得するためにはそういった詳細な理解も必要ですが、プライベートでの利用程度であれば、とりあえず一つの方法が分かっていれば実用上は問題ありません。

最近は MySQL や PostgreSQL などの OSS-DB や NoSQL などの利用が広がり、データベースとしての Oracle は下火になりつつあると言われていますが、個人的には Oracle Database が好きなので、次は Oracle Cloud に手を出そうかと思っています。

仕事でしかデータベースを触っていない方は、ぜひ一家に一データベースを Oracle Database で構築してみてはいかがでしょうか。

PC が重くなるという方は Oracle Cloud もありますよｗ

【Django3.0】TypeScript と Sass でフロントエンドを書く【webpack4】

はじめに

Django で Web アプリケーションを開発する際、フロントエンドを TypeScript と Sass で書いて webpack でトランスパイル ＆ バンドルする方法をまとめました。

ここでのフロントエンドとは、 Angular や React といったフレームワークを使わずに、 TypeScript と Sass で書いたファイルを webpack で JavaScript と CSS にトランスパイルして、静的ファイルとして Django テンプレートで読み込むことを指しています。

前提条件

• Django がインストールされており、プロジェクトとアプリケーションの作成・設定が完了している
• Node.js がインストールされており、npm init を行い package.json が作成されている

※ Django のインストールと初期設定については、以下の記事を参考にしてください。

ai-can-fly.hateblo.jp

動作環境

OS	Version
Windows 10 Pro	1909

Application	Version
PowerShell	5.1.18362.752

Environment	Version
Node.js	12.16.2
npm	6.14.4

Language	Version
Python	3.8.1

Package	Version
Django	3.0.4
webpack	4.43.3
webpack-cli	3.3.11
typescript	3.8.3
ts-loader	7.0.1
sass	1.26.5
sass-loader	8.0.2
css-loader	3.5.3
mini-css-extract-plugin	0.9.0
postcss-loader	3.0.0
autoprefixer	9.7.6

最終的にやりたいこと

• Django のアプリケーション毎に static ディレクトリを作り、その中に TypeScript と Sass のファイルを置く
• webpack の entry (エントリーポイント) と output (出力先ディレクトリ) を、 Django のアプリケーション単位に設定にする
• webpack で TypeScript と Sass を、それぞれ JavaScript と CSS にトランスパイルする
• Django のテンプレートで、トランスパイルされた JavaScript と CSS を読み込む

Django プロジェクトの構成

[django_project]
├ [django_application_a]
│ ├ static
│ │ └ [django_application_a]
│ │   ├ css
│ │   │ ├ index.scss
│ │   │ └ main.bundle.css      ← [application_a] のバンドルファイル
│ │   └ js
│ │     ├ index.ts             ← [application_a] のエントリーポイント
│ │     └ main.bundle.js       ← [application_a] のバンドルファイル
│ └ templates
│   └ [django_application_a]
│     └ index.html             ← main.bundle.js と main.bundle.css を読み込むテンプレートファイル
└ [django_application_b]
  ├ static
  │ └ [django_application_b]
  │   ├ css
  │   │ ├ index.scss
  │   │ └ main.bundle.css      ← [application_b] のバンドルファイル
  │   └ js
  │     ├ index.ts             ← [application_b] のエントリーポイント
  │     └ main.bundle.js       ← [application_b] のバンドルファイル
  └ templates
    └ [django_application_b]
      └ index.html             ← main.bundle.js と main.bundle.css を読み込むテンプレートファイル

エントリーポイント

index.ts

import '../css/index.scss'

console.log('Hello TypeScript and Sass !!');

各 Django アプリケーションのエントリーポイントの TypeScript ファイルで、 Sass ファイルをインポートします。

パッケージインストール

必要な npm パッケージをインストールします。

npm ではなく Yarn でも可です。

webpack

npm install --save-dev webpack webpack-cli

webpack と CLI で webpack を操作するために webpack-cli をインストールします。

TypeScript

npm install --save-dev typescript ts-loader

typescript と webpack で TypeScript を読み込むために ts-loader をインストールします。

Sass

npm install --save-dev sass sass-loader

sass と webpack で Sass を読み込むために sass-loader をインストールします。

CSS

npm install --save-dev css-loader mini-css-extract-plugin postcss-loader autoprefixer

@import などの依存関係の解決に css-loader 、CSS ファイルを出力するために mini-css-extract-plugin 、ベンダープレフィックスを付与するために postcss-loader と autoprefixer をインストールします。

ちなみに、ベンダープレフィックスの付与は必須ではありません。

設定ファイル

TypeScript

tsc コマンドで tsconfig.json を作成し、トランスパイルの設定を記述します。

npx tsc --init

tsconfig.json

{
  "compilerOptions": {
    "module": "es2015",  // モジュール出力
    "sourceMap": true,  // ソースマップ出力
    "target": "es5",  // 変換先 ECMAScript バージョン
    "strict": true,  // 以下のオプションを一括で有効化
                     // --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictBindCallApply, 
                     // --strictNullChecks, --strictFunctionTypes, --strictPropertyInitialization
    "forceConsistentCasingInFileNames": true  // ファイル名の大文字小文字を区別する
  }
}

webpack

webpack の設定ファイルは CLI コマンドからの生成は出来ないので、ファイルを手動で作成します。

webpack.config.js

const path = require('path');
const autoprefixer = require('autoprefixer');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  // モード
  mode: 'development',

  // エントリーポイント
  entry: {
    '[application_a]/static/[application_a]/js/main': path.resolve(
      __dirname,
      '[application_a]/static/[application_a]/js/index.ts'
    ),
    '[application_b]/static/[application_b]/js/main': path.resolve(
      __dirname,
      '[application_b]/static/[application_b]/js/index.ts'
    )
  },

  // ファイル出力先
  output: {
    // 出力先ディレクトリ
    path: __dirname,
    // 出力ファイル名
    filename: '[name].bundle.js',
  },

  // ソースマップ
  devtool: 'cheap-module-eval-source-map',

  // ローダー
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'ts-loader',
      },
      {
        test: /\.scss$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
            options: {
              esModule: true,
            },
          },
          {
            loader: 'css-loader',
            options: {
              url: false,
              sourceMap: true,
              importLoaders: 2,
            },
          },
          {
            loader: 'postcss-loader',
            options: {
              plugins: () => [autoprefixer()],
            },
          },
          {
            loader: 'sass-loader',
            options: {
              implementation: require('sass'),
              sassOptions: {
                includePaths: ['./node_modules'],
              },
              sourceMap: true,
            },
          },
        ],
      },
    ],
  },

  // モジュール解決
  resolve: {
    extensions: ['.ts', '.js'],
  },

  // プラグイン
  plugins: [
    new MiniCssExtractPlugin({
      moduleFilename: ({ name }) =>
        `${name.replace('/js/', '/css/')}.bundle.css`,
    }),
  ],
};

Django アプリケーション毎に JavaScript ファイルと CSS ファイルを出力するために、以下の点を考慮します。

• entry には Django アプリケーション単位でエントリーポイントを指定する
• entry に指定するオブジェクトのキーに出力先パスとファイル名の一部を指定する
• output で JavaScript の出力ファイル名を指定する
• plugins の MiniCssExtractPlugin で CSS の出力ファイル名を指定する

ポイントは entry で指定したオブジェクトのキーが、 output の [name] と plugins の MiniCssExtractPlugin の name に代入されるということです。

entry のキーにはファイル名だけでなく、パスを含む文字列が指定できるので、 Django アプリケーション毎のエントリーポイントまでのパスをキーとすることで、結果的にバンドルファイルも Django アプリケーション毎に出力することができます。

package.json

webpack を使用する上で必ず必要なものではありませんが、 npm-script によく使うコマンドを登録しておくと便利です。

{
  "name": "django-project",
  "version": "0.0.1",
  "main": "index.js",
  "private": true,
  "devDependencies": {
    "autoprefixer": "^9.7.6",
    "css-loader": "^3.5.3",
    "mini-css-extract-plugin": "^0.9.0",
    "postcss-loader": "^3.0.0",
    "sass": "^1.26.5",
    "sass-loader": "^8.0.2",
    "ts-loader": "^7.0.1",
    "typescript": "^3.8.3",
    "webpack": "^4.43.0",
    "webpack-cli": "^3.3.11"
  },
  "scripts": {
    "build": "webpack",
    "watch": "webpack --watch",
    "prod": "webpack --mode=production"
  }
}

ここでは通常の webpack コマンドに加え、開発時によく使う watch オプションと、本番用の production モードの三種類を npm-script に追加しました。

テンプレートファイル

Django のテンプレートファイルには、 webpack でコンパイルされた JavaScript ファイルと CSS ファイルを読み込むように記述します。

{% load static %}
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <link rel="stylesheet" href="{% static "[application_name]/css/main.bundle.css" %}">
    <title>Django</title>
  </head>
  <body>
    Hello Django !!
    <script src="{% static "[application_name]/js/main.bundle.js" %}"></script>
  </body>
</html>

webpack の実行

package.json に npm-script として webpack のコマンドを登録している場合は、 npm run コマンドで webpack を実行します。

npm-script ではなく、直接 webpack コマンドで実行しても同様なので、この辺りはお好みで。

開発用

# npm-script
npm run watch

# npx
npx webpack --watch

watch オプションを付けて webpack コマンドを実行すれば、コードを変更する度に再コンパイルされるので、開発時に都度 webpack コマンドを実行する必要が無くなります。

Web 上で、「watch オプションを使用した場合、変更したコードの差分のみのコンパイルとなるので処理が高速化する」という記事をいくつか目にしましたが、 webpack 公式ドキュメントでは同様の記述を見付けられなかったので、真偽のほどは不明です…

本番用

# npm-script
npm run prod

# npx
npx webpack --mode=production

mode を production に設定すると、 minimize が true になるなど、本番環境での使用を想定したコンパイルが行われます。

出力ファイル

コンパイルされたファイルは、各 Django アプリケーション毎に static ディレクトリの js / css ディレクトリ内にそれぞれ出力されます。

[django_project]/[django_application]/static/[django_application]/js/main.bundle.js
[django_project]/[django_application]/static/[django_application]/css/main.bundle.css

テンプレートファイルには、出力された JavaScript ファイルと CSS ファイルを読み込むように記述します。 (テンプレートファイル を参照)

おわりに

今回紹介した内容は、単純に Django で TypeScript と Sass が使えるようになっただけではなく、 npm で配布されている様々なパッケージが使用できるようになったことを意味します。

例えば、マテリアルデザインを手軽に実装できる Material Components や 老舗の Bootstrap 、 JavaScript でグリッドを出力できる ag-Grid など、 npm でパッケージをインストールして使用すれば、 webpack がまとめてコンパイルしてくれます。

CDN から読み込んで使用する方法もありますが、ローカルにソースがあれば IDE の自動補完や定義への移動が使えるので、個人的には npm でインストールしてコンパイルする方をお勧めします。

条件を満たしていれば、 Tree Shaking によるデッドコード除去や、 Code Splitting での遅延ロードの実現など、一概に webpack より CDN の方が良いとは言い切れないと思いますので、まずはローカルインストールでもいいのではないでしょうか。

これで TypeScript + Sass + Django の組み合わせで Web アプリが作れるようになりました。

もうコードを書かない理由は無くなりましたね _(┐「ε:)_

【Prettier】「なんとなく使う」から「分かって使う」へ【Visual Studio Code】

はじめに

皆さん、 Prettier は使っていますか？

フロントエンドのコードフォーマッターのデファクトスタンダード、もはや使っていない人はいないと言っても過言ではないでしょう。（過言です）

僕も普段は Visual Studio Code (以降、 VSCode) でコードを書いていますが、 Prettier は VSCode の拡張機能をインストールして使用しています。

そんな Prettier ですが、 VSCode で使用するにあたって、どこまで理解して使っているでしょうか？

VSCode で Prettier 拡張機能をインストールしたら動いたから、あとは設定を適当にいじって使っている。

そんな人はいませんか？（ちょっと前の僕です）

今回はそんな「なんとなく使う」から「分かって使う」ために、 VSCode 上での使い方を含めて Prettier についてまとめてみました。

Prettier の細かい設定については当記事では触れませんので、公式ドキュメントの Options をご覧ください。

prettier.io

前提条件

• Visual Studio Code をインストール済み
• Node.js をインストール済み

動作環境

OS	Version
Windows 10 Pro	1909

Application	Version
Visual Studio Code	1.44.2
PowerShell	5.1.18362.752
Node.js	12.16.2
npm	6.14.4
Yarn	1.22.4

Package	Version
Prettier	2.0.5
esbenp.prettier-vscode	4.5.0

大事なことを最初に

VSCode で初めて Prettier を使用するときに、何も知らない人 (当時の僕のような) が躓くであろうポイントを最初に書いておきます。

僕ははじめ、 VSCode で Prettier 拡張機能をインストールして、設定を適当にいじったらコードがフォーマットされたため、これで Prettier が使えるものだと思っていました。

たしかに上記の方法でも Prettier は使えるのですが、厳密には Prettier と VSCode の Prettier 拡張機能は別物で、しかも Prettier 拡張機能の公式が推奨している使用方法ではありません。

当記事ではその辺りの整理をしつつ、 Prettier 拡張機能の公式ドキュメントで推奨されている使い方について記載しています。

ざっくり Q&A

とりあえず目を通しておくと、この先の話が理解しやすいかもしれないことを Q&A 形式でまとめました。

Question	Answer
Prettier is 何？	Prettier はコードフォーマッターです。
Prettier はどうやってインストールするの？	Prettier は npm や Yarn などのパッケージマネージャーでインストールします。
Prettier はどうやって実行するの？	Prettier は CLI や Git Hooks など様々な方法で実行することができます。
Prettier と VSCode の Prettier 拡張機能は違うものなの？	VSCode の Prettier 拡張機能には Prettier がバンドルされていますが、とりあえずここでは違うものとしておきます。
VSCode の Prettier 拡張機能は何をするものなの？	VSCode 上で Prettier を実行してくれるプラグインみたいなものです。
Prettier の設定はどうやってするの？	Prettier の設定は設定ファイル (.prettierrc) で行います。
VSCode の設定 (settings.json) に Prettier の項目があるけど？	それは VSCode の Prettier 拡張機能の設定です。

Prettier

それでは、さっそく Prettier の使い方について書いていきます。

いったん VSCode の Prettier 拡張機能のことは忘れましょう。

インストール

まずは、お好みのパッケージマネージャーで Prettier をインストールします。

# npm
npm install --save-dev prettier

# Yarn
yarn add prettier --dev

そう、 Prettier は npm パッケージとして提供されていて、 Node.js 上で実行されるものなのです！

ここでは、とあるプロジェクトにローカルインストールしていますが、グローバルインストールも可能です。

※ npm や Yarn についての詳細は、当記事では扱いません。

設定ファイル (.prettierrc)

次に Prettier の設定ファイルを作成します。

設定は様々な拡張子で書くことができますが、今回は package.json の次に優先度の高い「.prettierrc (拡張子無し)」で設定ファイルを作成しましょう。

ローカルインストールした場合は、プロジェクトルートに設定ファイルを配置します。

[project_root]/.prettierrc

ちなみに、 Prettier はフォーマットするファイルを起点にファイルツリーを遡って設定ファイルを検索するので、プロジェクトルートやユーザのホームディレクトリなど、任意の場所に設定ファイルを置いてスコープを管理することができます。

詳細な設定は Prettier 公式ドキュメントを参照するとして、例として僕が使用している Prettier の設定を JSON 形式で書いてみました。

{
  "arrowParens": "always",
  "bracketSpacing": true,
  "endOfLine": "lf",
  "htmlWhitespaceSensitivity": "css",
  "insertPragma": false,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "printWidth": 80,
  "proseWrap": "preserve",
  "quoteProps": "as-needed",
  "requirePragma": false,
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "useTabs": false,
  "vueIndentScriptAndStyle": false
}

prettier.io

フォーマット実行 (CLI)

設定ファイルを作成したら、 Prettier を実行してファイルをフォーマットしてみましょう。

Prettier には様々な実行方法がありますが、今回は CLI での実行例を示します。

まずは、フォーマット対象の JavaScript ファイル (dirty.js) を以下の内容で作成し、 Prettier をローカルインストールしたプロジェクト内に保存します。

function    hello  (  )
{
      console.log('Hello Prettier !!');
}

保存したらファイルを閉じて、 CLI で prettier コマンドを実行します。

npx prettier --write dirty.js

実行後、ファイルを再度開いてみましょう。

function hello() {
  console.log('Hello Prettier !!');
}

きれいにフォーマットされていたら、無事 Prettier は実行されています。

これで今日から (見た目だけは) きれいなコードを書くことができますね！

prettier コマンド

prettier [options] [file/dir/glob ...]

Options	Description
--check	フォーマット済みかどうかをチェックする
--write	フォーマットを実行して保存する

フォーマット対象はファイル単位の他に、ディレクトリ単位や glob (ワイルドカード) で複数のファイルをまとめて指定することが可能です。

まとめ

Prettier の基本的な使い方をまとめると、

• Prettier をパッケージマネージャーでインストールする
• 設定ファイルを作る
• CLI で prettier コマンドを実行してフォーマットする

となります。

思ったより単純でしたよね？

でも、例えば開発時を想定した時、エディタでコードを編集した後に毎回 prettier コマンドを実行するのってめちゃくちゃ面倒じゃないですか？

そんな怠惰 (誉め言葉) なエンジニアさんは、 VSCode で Prettier 拡張機能を使いましょう。

※ 他のエディタ (例えば Atom など) でも Prettier を自動実行する方法はありますが、今回は VSCode だけを取り上げます。

Visual Studio Code の Prettier 拡張機能

さて、記憶から抹消していた VSCode の Prettier 拡張機能について触れる時がやってきました。

何ができるのか

Prettier の使い方は説明してきた通りですが、 CLI でいちいちコマンドを実行するのは手間がかかるので、自動化できたら便利ですよね。

VSCode の Prettier 拡張機能は、まさに上記を体現したかのような拡張機能で、 VSCode 上で Prettier を自動で実行してくれるスーパー便利なやつなのです。

コードの保存時やペースト時に自動実行させたり、キーボードのショートカットで実行できたりと、実行方法も様々あります。

それでは Prettier 拡張機能を使用して、先程プロジェクトにローカルインストールした Prettier を実行してみましょう。

インストール

インストールは非常に簡単で、サイドバーの拡張機能から Prettier を検索して「インストール」ボタンをクリックするだけです。

設定 (settings.json)

VSCode の設定は、 GUI で行う方法と設定ファイル (settings.json) を直接編集する方法があり、どちらの方法でも行うことができます。

ただし、今回紹介するように言語単位で設定を行う場合は、設定ファイル (settings.json) を直接編集することになります。

今回はすべて設定ファイル (settings.json) で設定していきます。

既定のフォーマッター (Default Formatter)

VSCode には VSCode 標準フォーマッター (vscode.***-language-features) が付属しているため、既定のフォーマッターを Prettier (esbenp.prettier-vscode) に変更する必要があります。

// すべての言語を対象に既定のフォーマッターを設定する場合
"editor.defaultFormatter": "esbenp.prettier-vscode",

// 言語単位で既定のフォーマッターを設定する場合
"[javascript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode"
},

Prettier がサポートする言語については、 Prettier 公式ドキュメントを確認してください。

prettier.io

保存時にフォーマット (Format On Save)

VSCode でファイルを保存した時に、フォーマットを行うかどうかを設定します。

// すべての言語で保存時にフォーマットを行う
"editor.formatOnSave": true,

// 言語単位で保存時にフォーマットを行うか設定する
"[javascript]": {
    "editor.formatOnSave": true
},

貼り付け時にフォーマット (Format On Paste)

コードを貼り付ける際にフォーマットを行うかどうかを設定します。

// すべての言語で貼り付け時にフォーマットを行う
"editor.formatOnPaste": true,

// 言語単位で貼り付け時にフォーマットを行うか設定する
"[javascript]": {
  "editor.formatOnPaste": true
},

入力時にフォーマット (Format On Type)

コード入力時にフォーマットを行うかどうかを設定します。

// すべての言語でコード入力時にフォーマットを行う
"editor.formatOnType": true,

// 言語単位でコード入力時にフォーマットを行うか設定する
"[javascript]": {
  "editor.formatOnType": true
},

※ コード入力時というのは、一文字ずつ入力する度にフォーマットが実行されるのではなく、改行入力時や JavaScript であれば文末のセミコロン入力時にフォーマットが実行されます。入力した行単位でフォーマットが実行される感じです。

使い方

VSCode では、設定ファイル (settings.json) に基づき、既定のフォーマッターが設定されたタイミングで実行されます。

Prettier を既定のフォーマッターにし、任意のタイミングでフォーマットを行う設定にすることで、 Prettier の自動実行を実現させているというわけです。

例えば、保存時にフォーマットを行う設定にするだけで、ファイルを編集する度に Prettier を手動で実行する手間から完全に解放されるのです！

ためしに、先程作成した JavaScript ファイル (dirty.js) をもう一度開いて、インデントや半角スペースをぐちゃぐちゃにしてみましょう。

そして、おもむろに Ctrl + S で保存すると…

きれいにフォーマットされました！よね！？

VSCode ではキーボードショートカット (Shift + Alt + F) でフォーマットを実行することができるので、コードの入力中に好きなタイミングで Prettier を実行することもできます。

Prettier 拡張機能マジ便利！

これで今日から VSCode で (見た目だけは) きれいなコードを書きまくれるぞ！

まとめ

いやー、 VSCode の Prettier 拡張機能ってめちゃくちゃ便利ですねー。

それでは以上で Prettier 拡張機能の使い方を終わります…って、あれ？

「はじめに」でも書いた通り、何も分からずに使っていた頃はプロジェクトに Prettier なんてインストールしてないし、もちろん設定ファイル (.prettierrc) も作ってないし、 VSCode の Prettier 拡張機能をインストールして設定 (settings.json) をいじっただけでフォーマットできていたような？

そう、これが僕のような初心者が陥る罠なのですが、なんと VSCode の Prettier 拡張機能には Prettier 本体がバンドルされて (含まれて) いるのです！

つまり、 Prettier 拡張機能さえインストールしていれば、 VSCode では Prettier が使えるということなんです！

設定 (settings.json) に Prettier の細かい設定があるのも、そこで設定された内容で Prettier のフォーマットを実行するためなのです。

えー、じゃあ別に Prettier 本体をインストールする必要は無いし、設定ファイル (.prettierrc) も作らなくていいんじゃないの？と思ってしまいそうですが、 Prettier 拡張機能の公式ドキュメントにはプロジェクトのローカルにインストールされている Prettier と設定ファイルを使用することを推奨する旨がしっかり記載されています。

marketplace.visualstudio.com

これは当然といえば当然ですが、チームで開発する場合はパッケージのバージョンや設定を揃えないといけないですし、そもそも VSCode 以外のエディタを使っている人もいるかもしれないので、設定の統一が難しくなってしまいます。

Prettier 拡張機能にバンドルされている Prettier や VSCode の設定は、あくまでもフォールバック的な位置付けで、優先される設定もローカルの Prettier 設定ファイル (.prettierrc) が上位になっています。

ローカルに Prettier 設定ファイル (.prettierrc) が存在し、一つでも設定項目が書かれている場合、 VSCode の Prettier の設定はすべて適用されません。

Prettier 拡張機能は、ローカルにインストールされている Prettier を VSCode 上で実行するための補助機能として使うことをお勧めします。

おわりに

だいぶ長くなりましたが、これで Prettier について何となくは理解できたでしょうか。

「なんか知らんけどフォーマットはできている」状態から「Prettier 完全に理解した」レベルにはなれたんじゃないかと思います。

ただ、一般的に Prettier を使うプロジェクトの場合、リンターに ESLint を使用しているケースが大半で、僕も ESLint を併用していたりします。

Prettier と ESLint はフロントエンドではセットで使用するのがデファクトスタンダードになっており、これらの知識は必須と言えます。

セットで使用するのが当たり前と言いつつ、素直にそのまま併用すると問題が出たりするので、この辺りもフロントエンドがややこしいと言われる一端…は言い過ぎでしょうか…

ということで、 ESLint についてはまた別記事でまとめたいと思います。

最後までお読みいただき、ありがとうございました！

【Django3.0】開発環境構築から初期設定まで【Python3.8】

はじめに

Django で開発を行うにあたり、開発環境の構築からプロジェクトの初期設定など、ビジネスロジックの実装以外で基本的に一度やったらそれで終わりの作業をまとめました。

「えーと、 Django のプロジェクト作るには何をすればよかったんだっけ…」「あー！あの設定漏れてた！」と、僕がなることのまとめです。

新規に Django プロジェクトとアプリケーションを作成し、開発用の Web サーバを起動して Web ブラウザに Hello Django !! と表示するところまでをまとめました。

動作環境

OS	Version
Windows 10 Pro	1909

Application	Version
PowerShell	5.1.18362.752

Language	Version
Python	3.8.1

Package	Version
Django	3.0.4

開発環境構築

まずは、必要なパッケージのインストールやプロジェクトの作成から。

Python 仮想環境作成

最初に Python の仮想環境を作成します。

python -m venv venv

インストール

次に仮想環境へ切り替えを行い、 Django をインストールします。

./venv/Scripts/activate

pip install django

プロジェクト作成

インストールが完了したら、 Django のプロジェクトを作成します。

プロジェクトディレクトリを作成する場合

django-admin startproject [project_name]

カレントディレクトリにプロジェクトディレクトリが作成され、その中に Django アプリケーションの各構成ファイルが作成されます。

カレントディレクトリ ＝ プロジェクトディレクトリの場合

django-admin startproject [project_name] .

カレントディレクトリに Django アプリケーションの各構成ファイルが作成されます。

アプリケーション作成

次に、プロジェクトルート直下にアプリケーションを作成します。

アプリケーション作成コマンドは、プロジェクトルートで実行します。

python manage.py startapp [application_name]

Django 初期設定

開発環境の構築が完了したら、プロジェクトの初期設定を行います。

プロジェクト

Django プロジェクトに関する設定は、プロジェクトディレクトリ内の設定ファイル (settings.py) で行います。

設定ファイル (settings.py)

[project_root]/[project_name]/settings.py

言語 (LANGUAGE_CODE)

-- LANGUAGE_CODE = "en-us"
++ LANGUAGE_CODE = "ja"

タイムゾーン (TIME_ZONE)

-- TIME_ZONE = "UTC"
++ TIME_ZONE = "Asia/Tokyo"

データベース (DATABASES)

   DATABASES = {
       "default": {
--     "ENGINE": "django.db.backends.sqlite3",
--     "NAME": os.path.join(BASE_DIR, "db.sqlite3"),
++     "ENGINE": "django.db.backends.oracle",
++     "NAME": "[host]:[port]/[db_name].[db_domain]",
++     "USER": "[user]",
++     "PASSWORD": "[password]",
    }
}

Django では複数のデータベースを公式にサポートしており、ここでは例として Oracle Database への接続方法を記載しています。

テンプレート (TEMPLATES)

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",
            ],
        },
    },
]

APP_DIRS を True にすると、各アプリケーションディレクトリ直下の templates ディレクトリ内にあるテンプレートを参照する。

APP_DIRS のデフォルト値は True なので、特に変更の必要はありません。

インストールアプリケーション (INSTALLED_APPS)

   INSTALLED_APPS = [
++     "[application_name].apps.[AppConfig]",
       "django.contrib.admin",
       "django.contrib.auth",
       "django.contrib.contenttypes",
       "django.contrib.sessions",
       "django.contrib.messages",
       "django.contrib.staticfiles",
   ]

作成したアプリケーションの AppConfig を INSTALLED_APPS に追加し、アプリケーションを有効化します。

プロジェクトに含めるアプリケーションは INSTALLED_APPS に追加する必要があり、逆に言えばここに追加しなければマイグレーション等の対象にはなりません。

プロジェクト作成時に既にいくつかのアプリケーションが追加されていますが、不要なものがあれば削除しても問題ありません。

ルーティング (urls.py)

URLconf で URL パターンをビューにマッピングします。

プロジェクトルート直下の URLconf では、主に各アプリケーションの URLconf への参照設定を行います。

[project_root]/[project_name]/urls.py

   urlpatterns = [
       path("admin/", admin.site.urls),
++     path("[application_name]/", include("[application_name].urls")),
   ]

プロジェクトルートから作成したアプリケーションまでのルーティングを追加する。

アプリケーション

ここからはアプリケーションディレクトリ内の各構成ファイルについてです。

ビュー (views.py)

Django のビューは、関数ベースとクラスベース (汎用ビュー) の二種類存在しますが、ここでは関数ベースのビューを例示しています。

[project_root]/[application_name]/views.py

   from django.shortcuts import render

++ def index(request):
++     context = {"framework": "Django"}
++     return render(request, "[application_name]/index.html", context)

ビューの役割は、データベースからのデータ取得やテンプレートのロード、レンダリングしたテンプレートの返却など多岐にわたります。

主なビジネスロジックはビューに実装することになります。

テンプレート (templates ディレクトリ)

[project_root]/[application_name]/templates/[application_name]/

プロジェクト設定ファイル (settings.py) の TEMPLATES.APP_DIRS を True にした場合、アプリケーションディレクトリ直下の templates ディレクトリ内が参照されます。

templates ディレクトリ直下にテンプレートファイルを置かず、 [application_name] ディレクトリを作成してから、その中にテンプレートファイルを配置します。

テンプレートの名前空間 - Django チュートリアルより要約

Django では名前がマッチした最初のテンプレートを使用するので、異なるアプリケーションの中に同じ名前のテンプレートがあった場合、それらを区別することができません。

templates ディレクトリ直下に [application_name] サブディレクトリを作り、その中にテンプレートファイルを配置することで、名前空間を作成することができます。

Django にはテンプレート内で使用できる独自のテンプレート言語が存在します。

ここで例示しているテンプレートは、ビューから渡されたコンテキスト変数の framework の値を展開し、レンダリングされます。

[project_root]/[application_name]/templates/[application_name]/index.html

++ <!DOCTYPE html>
++ <html lang="ja">
++ <head>
++   <meta charset="utf-8">
++   <title>Django Application</title>
++ </head>
++ <body>
++   Hello {{ framework }} !!
++ </body>
++ </html>

ルーティング (urls.py)

アプリケーション作成コマンドでは、アプリケーションディレクトリに URLconf (urls.py) は作成されないため、自分で作る必要があります。

[project_root]/[application_name]/urls.py

++ from django.urls import path

++ from . import views

++ app_name = "[application_name]"
++ urlpatterns = [
++     path('', views.index, name='index'),
++ ]

プロジェクトルートの URLconf から渡された URL パターン (URL からプロジェクトルートの URLconf で定義された URL パターンを除いた文字列) と、ビューをマッピングします。

モデル (models.py)

[project_root]/[application_name]/models.py

Django では、データベースのテーブルを Python のクラスで表現し、カラムをクラス変数として定義します。

テーブルとクラスが一対一で紐づき、これが一つのモデルとなります。

今回は Hello Django !! と表示するだけなのでモデルは必要ありませんが、モデルの簡単な書き方だけ例示します。

from django.db import models

class [class_name](models.Model):
    [column_name_1] = models.IntegerField(primary_key=True)
    [column_name_2] = models.CharField(max_length=[length])
    [column_name_3] = models.DateField()
    [column_name_4] = models.ForeignKey(
        "[other_class_name]", models.DO_NOTHING, db_column="[other_column_name]"
    )

    class Meta:
        managed = True
        db_table = "[table_name]"

既にデータベースにテーブルが存在する場合

Django には、既存のデータベースからモデルを自動生成するユーティリティが備わっています。

python manage.py inspectdb > [application_name]/models.py

inspectdb コマンドを実行すると、プロジェクト設定ファイルの DATABASES に設定されているデータベースのテーブルを読み込み、 Django モデルモジュールを標準出力に出力します。

上記の例では、 inspectdb コマンドの出力結果をリダイレクトし、直接 models.py に書き込んでいます。

マイグレーション

アプリケーションのモデルで定義した内容をデータベースに反映するために、マイグレーションを実行します。

Django では、マイグレーションの作成と適用それぞれにコマンドが用意されています。

マイグレーション作成

makemigrations コマンド

python manage.py makemigrations

# アプリケーション単位でマイグレーションファイルを作成
python manage.py makemigrations [application_name]

makemigrations コマンドを実行すると、 プロジェクト設定ファイルの INSTALLED_APPS に設定されているアプリケーションのモデルを読み込み、各アプリケーションディレクトリの migrations ディレクトリ内にマイグレーションファイルが作成されます。

マイグレーション実行

sqlmigrate コマンド

python manage.py sqlmigrate [application_name] [migration_name]

migrate コマンドを実行する前に、 sqlmigrate コマンドで実際にデータベースへ発行される SQL を確認することができます。

migrate コマンド

python manage.py migrate

migrate コマンドを実行すると、 makemigrations コマンドで作成されたマイグレーションの内容がデータベースに反映されます。

開発用サーバ

Django には、開発を迅速に行うために Python だけで書かれた軽量な Web サーバが付属しています。

サーバ起動

runserver コマンド

python manage.py runserver [port]

runserver コマンドを実行すると、 Web サーバが起動します。

引数として、ポート番号を指定することもできます。

ポート番号のデフォルト値は 8000 です。

Web ブラウザで確認

runserver コマンドで起動した Web サーバには、 http://localhost:[port] でアクセスできます。

Django の開発用サーバは、デフォルトではコードを変更して保存する度に自動リロードされる設定になっています。

http://localhost:[port]/[application_name]/ にアクセスし、 Hello Django !! と表示されれば、今回の Django アプリケーションは正常に動作しています。

おわりに

今回は、 Django プロジェクトを新規で立ち上げた際に行うことを中心にまとめました。

実際の開発では、今回取り上げなかったクラスベースの汎用ビューや、フォーム (forms.py) 、管理サイト (Django Admin) など、他にも多くの Django の機能を使用することになると思います。

さらに、 SPA (Single Page Application) との組み合わせに Django REST framework 、ソーシャルログインを実装するために social-auth-app-django 、 WSGI サーバを立てるために Gunicorn など、 Django だけでなくサードパーティ製のパッケージも必要になることもあります。

覚えることが多くて大変と思いがちですが、一度覚えてしまえばアプリケーションの実装に集中できるので、やっぱりフレームワークは便利です。

というか、フレームワークを使用せずにすべてを自前で実装する方が絶対大変です…

それでは、皆様も良い Django ライフを！