お疲れ様です。

今回は、commitzenに似た機能を実現できる、シェルスクリプトを作成しましたので、共有します。

commitzenの問題

コミットメッセージを標準化する方法として、「commitzen」が挙げられると思います。

GitHub - commitizen/cz-cli: The commitizen command line utility. #BlackLivesMatter

The commitizen command line utility. #BlackLivesMatter - commitizen/cz-cli

github.com

しかし、このツールは、毎回インストールする手間や、Node.jsベースで、プロジェクトによっては追加の依存関係が必要になったりします。

そのような際、別の選択肢を一から探すのは手間です。

そのため、今回、シェルスクリプトを作成して、いかなるプロジェクトでも、同様のコミットメッセージを導入できるようにしました。

スクリプト

#!/bin/bash

# コミットタイプを尋ねる
echo "コミットのタイプを選択してください:"
echo "1. feat (新機能)"
echo "2. fix (バグ修正)"
echo "3. docs (ドキュメントの変更)"
echo "4. style (コードのスタイル変更、フォーマット等)"
echo "5. refactor (リファクタリング)"
echo "6. test (テスト関連)"
echo "7. chore (その他、ビルドプロセスや補助ツールの変更)"
echo "8. perf (パフォーマンス改善)"
echo "9. build (ビルドシステムや外部依存関係の変更)"
echo "10. ci (CI設定ファイルやスクリプトの変更)"
read -p "番号を入力してください: " type

case $type in
  1) type="feat";;
  2) type="fix";;
  3) type="docs";;
  4) type="style";;
  5) type="refactor";;
  6) type="test";;
  7) type="chore";;
  8) type="perf";;
  9) type="build";;
  10) type="ci";;
  *) echo "無効な選択肢です"; exit 1;;
esac

# スコープを尋ねる
read -p "変更のスコープ (コンポーネントやファイル名等) を入力してください: " scope

# コミットメッセージの概要を尋ねる
read -p "コミットメッセージの概要を簡潔に記述してください: " summary

# コミットメッセージの本文を尋ねる（オプション）
read -p "詳細なコミットメッセージを入力してください (オプション): " body

# コミットメッセージを組み立てる
commit_message="$type($scope): $summary"
if [ -n "$body" ]; then
  commit_message="$commit_message\\n\\n$body"
fi

# コミットを実行
git commit -m "$commit_message"

実行方法

上記のスクリプトの実行方法は、下記のコマンドを入力してください。

// ファイル名が「commit.sh」の場合
chmod +x commit.sh

そして、以下のコマンドで、スクリプトを実行してコミットを行います。

./commit.sh

おわり

今回のスクリプトは、基本的な機能しか持っていません。

プロジェクトのニーズに合わせて、カスタマイズしていってください。

The post 【Git】commitzenをシェルスクリプトで実行 first appeared on AichiLog.

はじめに

プログラミングにおいて、言語のバージョン管理は非常に重要な作業です。特に、複数のプロジェクトを同時に管理する場合、それぞれで必要な言語のバージョンが異なることがよくあります。この記事では、そんな課題を解決する万能ツールasdfについて詳しく解説します。

複数の言語を一括管理：asdfの強み

• プラグイン形式で拡張性が高い
  • asdfはプラグイン形式で、Node.jsからRuby、Pythonまで500近くの言語環境をサポートしています。
• 最新バージョンへの対応が早い
  • asdfは各言語の最新バージョンに迅速に対応しています。これにより、常に最新の環境で開発を進めることができます。

asdfの基本コマンド

• asdf plugin list：インストール済みのプラグイン一覧を表示
• asdf install <PLUGIN_NAME> <VERSION>：指定したプラグインとバージョンをインストール
• asdf global <PLUGIN_NAME> <VERSION>：グローバルに使うパッケージのバージョンを設定

事前準備：.default-npm-packagesファイルを作成しよう

次に、asdfでNode.jsをインストールする前に、一つ大事な手続きがあります。それは、ホームディレクトリに.default-npm-packagesというファイルを作成することです。このファイルには以下の内容を書き込んでください。

# .default-npm-packages ファイルの内容
yarn
typescript
ts-node
typesync
npm-check-updates

このファイルの役割とは？

この.default-npm-packagesファイルは、Node.jsの新しいバージョンをインストールする際に、自動的に一緒にインストールされるnpmパッケージを指定できる非常に便利なファイルです。これにより、毎回必要なnpmパッケージを手動でインストールする手間が省けます。

他のプログラミング言語でも同じような機能がある

RubyやPythonでも、同じような機能が利用できます。Rubyでは.default-gems、Pythonでは.default-python-packagesというファイルで、それぞれの言語でデフォルトでインストールしたいパッケージを指定できます。

実際にNode.jsをインストールしてみよう

# 1. Homebrewを使ってasdfをインストール
# Homebrewがインストールされていない場合は、先にそれをインストールしてください。
brew install asdf

# 2. Node.jsのプラグインを追加
# asdfにNode.jsのプラグインを追加します。
asdf plugin add nodejs

# 3. 最新バージョンのNode.jsをインストール
# Node.jsの最新バージョンをインストールします。
asdf install nodejs latest

# 4. グローバルに使うNode.jsのバージョンを設定
# インストールしたNode.jsのバージョンをグローバルで使用するように設定します。
asdf global nodejs latest

まとめ

asdfはその拡張性と多言語対応により、プログラミング言語のバージョン管理において非常に優れたツールです。特に複数のプロジェクトを管理する開発者にとっては、その効率と便利さは計り知れません。

The post なぜasdfがプログラミング言語のバージョン管理に最適なのか？ first appeared on AichiLog.

はじめに

Node.jsの世界では、npm（Node Package Manager）が長い間、唯一無二のパッケージ管理ツールでした。しかし、2016年に登場したYarnは、その新機能と高速性で多くの開発者の心をつかみました。この記事では、Yarnがどれほど魅力的なのか、その特長と利点について詳しく解説します。

Yarnが生まれた背景

Yarnは、Facebook（現在はMeta）が主導して2016年に公開されました。当時、npmには依存関係の管理が煩雑である、パフォーマンスが遅いなどの問題がありました。Yarnはこれらの問題を解決するために設計され、短期間で多くの開発者に受け入れられました。

Yarnの特長とその魅力

1. バージョン固定機能（yarn.lock）

Yarnの一番の特長は、yarn.lockというロックファイルを生成することで、依存パッケージのバージョンを固定する能力です。

なぜこれが素晴らしいのか？

• 安定性: 同じプロジェクトで複数の開発者が作業する場合でも、yarn.lockがあれば全員が同じバージョンの依存パッケージを使用することが保証されます。
• 予測可能性: バージョンが固定されているため、未知のバグや非互換性の問題を防ぐことができます。

2. 高速なパフォーマンス

Yarnは、npmよりも高速にパッケージをダウンロードとインストールができます。

なぜこれが素晴らしいのか？

• 効率性: 高速なインストールは、開発プロセスをスムーズにし、時間を節約します。
• CI/CDの高速化: 継続的インテグレーションと継続的デリバリー（CI/CD）の速度も向上します。

3. Workspaceのサポート

Yarnは、複数のプロジェクトやパッケージを一つのリポジトリ内で管理する「Workspace」という機能を提供しています。

なぜこれが素晴らしいのか？

• 一元管理: モノリポジトリの管理が容易になります。
• 依存関係の整合性: Workspaceを使用すると、プロジェクト間での依存関係が一元管理され、その整合性が保たれます。

Yarnの使い方：主要なコマンド

Yarnは、npmと非常に似たコマンドラインインターフェースを持っていますが、いくつか独自の便利なコマンドもあります。

• yarn install: 依存関係を解決し、パッケージをインストールします。
• yarn add <PACKAGE_NAME>: 新しいパッケージを追加します。
• yarn remove <PACKAGE_NAME>: 不要なパッケージを削除します。
• yarn upgrade: 既存のパッケージを最新バージョンにアップグレードします。

結論：Yarnはnpmの強力な代替品

Yarnは、npmに対して多くの優れた特長を持っています。特に、依存関係の管理、高速なパフォーマンス、そしてWorkspaceのサポートは、大規模なプロジェクトやプロフェッショナルな開発環境で非常に役立ちます。どちらのツールを選ぶかは、プロジェクトのニーズやチームの好みによるところが大きいですが、Yarnは多くの面で優れた選択肢と言えるでしょう。

この記事が、Yarnを採用するかどうかを検討している開発者の皆さんにとって、参考になれば幸いです。

The post Yarn vs npm: なぜ開発者はYarnを選ぶのか？ first appeared on AichiLog.

はじめに

開発プロジェクトでよく使われるパッケージマネージャー、Yarnとnpm。どちらもpackage.jsonのscriptsエントリを活用して、様々なコマンドを簡単に実行できます。この記事では、このscriptsエントリがどのように動作するのか、そしてそれがどれだけ便利なのかを詳しく解説します。

scriptsエントリの基本

package.jsonの中にはscriptsというエントリがあります。このエントリにコマンドを登録しておくと、Yarnやnpmで簡単にそのコマンドを実行できます。例えば、以下のような設定があった場合、

"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "preview": "vite preview"
}

Yarnではyarn dev、npmではnpm run devといった形で、viteコマンドが実行されます。

予約キーワードと特別な挙動

scriptsエントリには予約キーワードがあり、特別な挙動が設定されています。以下はその例です。

• start: 開発用サーバの起動
• restart: 開発用サーバの再起動
• stop: 開発用サーバの停止
• test: テストの実行

これらのキーワードは、特定のnpmコマンドや他のscriptsエントリの前後で自動的に実行される場合もあります。

フックとしての予約キーワード

さらに、preやpostをキーワードの前につけることで、特定の処理の前後にスクリプトを実行できます。例えば、

• preinstall, postinstall: パッケージインストールの前後
• preuninstall, postuninstall: パッケージアンインストールの前後
• prestart, poststart: startスクリプトの前後
• pretest, posttest: testスクリプトの前後
• prepare: インストール後の最終処理

これらは、開発フローをよりスムーズにするために非常に便利です。

まとめ

package.jsonのscriptsエントリは、Yarnとnpmでプロジェクトを効率よく管理するための強力なツールです。予約キーワードやフックを活用することで、より高度なスクリプト管理が可能になります。この機能を最大限に活用して、開発プロセスを効率化しましょう。

参考文献

• LifeCycleOperationOrder-scripts|npmDocs

この記事が役立ったと感じたら、ぜひシェアをお願いします！

The post Yarnとnpmのスクリプト管理：package.jsonのscriptsエントリを理解する first appeared on AichiLog.

それぞれにはメリットとデメリットがあり、プロジェクトの規模やチームの作業スタイルによって最適な選択が変わります。

今回は、これらの違いと使いどころをわかりやすく解説します。

デコロケーション（Decolocation）

概要と特徴

デコロケーションでは、関連するリソース（コンポーネント、スタイル、テスト、APIなど）を別々のディレクトリに配置します。

これは、特に小規模なプロジェクトや、特定の種類のファイルを一箇所で一元管理したい場合に有用です。

具体的なディレクトリ構成

- src/
  - components/
  - pages/
  - styles/
  - tests/
  - api/
- docs/

// デコロケーション（機能別にディレクトリを配置）

src/
├─ features/
│   ├─ FeatureA.tsx           # 機能A
│   ├─ FeatureB.tsx           # 機能B
│   └─ SubComponent.tsx       # サブコンポーネント
│
├─ components/                # 共通コンポーネント
│   ├─ SharedComponent.tsx    # 共有コンポーネント
│   └─ ...
│
├─ styles/                    # スタイルファイル
│   ├─ FeatureA.styles.ts
│   ├─ SubComponent.styles.ts
│   ├─ SharedComponent.styles.ts
│   └─ ...
│
└─ tests/                     # テストファイル
    ├─ FeatureA.test.ts
    ├─ SubComponent.test.ts
    ├─ SharedComponent.test.ts
    └─ ...

メリットとデメリット

メリット

• 一元管理: 同じ種類のファイルが一箇所にまとまっているため、一覧性が高く管理が容易です。
• 小規模プロジェクト向け: プロジェクトが小規模であれば、この方法で十分に管理が行えます。

デメリット

• 関連性が低い: 関連するファイルが物理的に離れているため、開発時に多くのディレクトリを行き来する必要があります。
• スケーラビリティの問題: プロジェクトが大きくなると、管理が煩雑になる可能性があります。

コロケーション

概要と特徴

コロケーションでは、関連するリソースを一箇所にまとめます。これにより、プロジェクトの可読性と保守性が向上します。特に大規模なプロジェクトや複数人での開発において有用です。

具体的なディレクトリ構成

- src/
  - pages/
    - Home/
  - components/
    - Button/
  - api/
    - User/

// コロケーション（関連するファイルを近くに配置）

src/
├─ features/
│   ├─ FeatureA.tsx           # 機能A
│   ├─ FeatureB.tsx           # 機能B
│   └─ SubComponent.tsx       # サブコンポーネント
│
├─ components/                # 共通コンポーネント
│   ├─ SharedComponent.tsx    # 共有コンポーネント
│   └─ ...
│
├─ styles/                    # スタイルファイル
│   ├─ FeatureA.styles.ts
│   ├─ SubComponent.styles.ts
│   ├─ SharedComponent.styles.ts
│   └─ ...
│
└─ tests/                     # テストファイル
    ├─ FeatureA.test.ts
    ├─ SubComponent.test.ts
    ├─ SharedComponent.test.ts
    └─ ...

メリットとデメリット

メリット

• 可読性: 関連するファイルが近くにあるため、コードの流れが理解しやすい。
• 保守性: 一箇所にまとまっているため、変更やリファクタリングが容易です。
• 開発速度: ファイルの行き来が減少し、開発がスムーズに行えます。

デメリット

• 複雑性: 大規模なプロジェクトで多くの関連ファイルが一箇所に集まると、そのディレクトリ自体が複雑になる可能性があります。
• ファイル探索: 関連ファイルが多い場合、特定のファイルを見つけるのが少し難しくなるかもしれません。

結論: どちらを選ぶべきか？

• 小規模プロジェクト: デコロケーションが適しています。管理がシンプルで、必要なリソースがすぐに見つかります。
• 大規模プロジェクトや複数人での開発: コロケーションが有用です。可読性と保守性が高く、開発効率も向上します。

プロジェクトの規模、チームの作業スタイル、将来のスケーラビリティなどを考慮して、最適なディレクトリ構成を選びましょう。

おまけ：デコロケーション、コロケーションの具体的なディレクトリ構成

最後に、Todoアプリを作成する場合のディレクトリ構成を、デコロケーション、コロケーションをもちいて作成します。

// デコロケーション

src/
├─ pages/                         # ページコンポーネント
│   ├─ HomePage.tsx               # ホームページ
│   ├─ TodoListPage.tsx           # Todoリストページ
│   └─ AboutPage.tsx              # アバウトページ
│
├─ components/                    # 共通コンポーネント
│   ├─ Navbar/                    # ナビゲーションバー
│   │   ├─ index.tsx
│   │   ├─ index.module.css
│   │   └─ ...
│   ├─ TodoItem/                  # Todo項目コンポーネント
│   │   ├─ index.tsx
│   │   ├─ index.module.css
│   │   └─ ...
│   └─ Button/                    # ボタンコンポーネント
│       ├─ index.tsx
│       ├─ index.module.css
│       └─ ...
│
├─ styles/                        # スタイルファイル
│   ├─ common.module.css          # 共通スタイル
│   └─ ...
│
└─ types/                         # 型定義ファイル
    ├─ commonTypes.ts             # 共通型定義
    └─ ...

// コロケーション

app/
├─ (root)/                   # ドメインルート用ディレクトリ
│   ├─ page.tsx             # ドメインルートのページ
│   ├─ _components/          # ドメインルート専用のコンポーネント
│   │   └─ Navbar/           # ナビゲーションバー用コンポーネント
│   │       ├─ index.tsx
│   │       ├─ index.module.css
│   │       └─ ...
│   └─ _types/               # ドメインルート専用の型定義
│       └─ types.ts
│
├─ TodoList/                 # Todoリストページ用ディレクトリ
│   ├─ page.tsx             # Todoリストのページ
│   ├─ _components/          # Todoリスト専用のコンポーネント
│   │   ├─ TodoItem/         # 各Todo項目用コンポーネント
│   │   │   ├─ index.tsx
│   │   │   ├─ index.module.css
│   │   │   └─ ...
│   │   └─ ...
│   └─ _types/               # Todoリスト専用の型定義
│       └─ types.ts
│
├─ About/                    # アバウトページ用ディレクトリ
│   └─ page.tsx             # アバウトページ
│
components/                   # 共通コンポーネント用ディレクトリ
├─ Button/                    # 汎用ボタンコンポーネント
│   ├─ page.tsx
│   ├─ index.module.css
│   └─ ...
│
types/                        # 全体的な型定義用ディレクトリ
└─ globalTypes.ts             # アプリ全体で使用する型定義

The post Next.jsにおけるディレクトリ構成: デコロケーション vs コロケーション first appeared on AichiLog.

良いコミットメッセージは、変更の内容を明確に伝え、他の開発者がプロジェクトの履歴を理解するのを助けます。

ここで、Commitizenというツールの出番です。Commitizenは、標準化されたコミットメッセージのフォーマットを簡単に作成するためのツールです。

Commitizenの始め方

インストール

Commitizenを使い始めるには、まず以下のコマンドでグローバルにインストールします。

npm install -g commitizen

これにより、git commitの代わりに使用するgit czコマンドが利用可能になります。

次に、日本語でコミットメッセージを作成するためのアダプターcz-conventional-changelog-jaをインストールします。

npm install -g cz-conventional-changelog-ja

設定の追加

プロジェクトのpackage.jsonファイルに以下の設定を追加します。

"config": {
  "commitizen": {
    "path": "cz-conventional-changelog-ja"
  }
}

この設定により、Commitizenは日本語でのコミットメッセージの作成をサポートするようになります。

コミットの作成

設定が完了したら、コミットを作成するために以下のコマンドを使用します。

git cz

このコマンドを実行すると、コミットの種類を選択するためのリストが表示されます。例えば、新しい機能の追加、バグ修正、ドキュメントの更新など、変更の種類に応じて適切なオプションを選ぶことができます。

Commitizenのメリット

• 標準化: Commitizenを使用すると、プロジェクト全体で一貫したコミットメッセージのフォーマットを維持できます。
• 自動化: コミットメッセージのフォーマットを手動で記憶する必要がなく、プロンプトに従って入力するだけで良い形式のメッセージを作成できます。
• チームワークの向上: 新しい開発者がプロジェクトに参加したときに、コミットメッセージのフォーマットに迅速に適応できます。

まとめ

Commitizenは、コミットメッセージの品質を維持し、開発プロセスをスムーズにするための素晴らしいツールです。

設定は簡単で、使い始めることも容易です。

日本語でのコミットメッセージをサポートするcz-conventional-changelog-jaを使えば、日本の開発チームでも効率的に活用することができます。

プロジェクトの歴史が読みやすくなり、チーム内のコミュニケーションが向上するでしょう。

参考文献

Commitizenを使ってgitのコミットメッセージをしっかり書こう | DevelopersIO

dev.classmethod.jp

The post Commitizenでプロフェッショナルなコミットメッセージを作成しよう first appeared on AichiLog.

ここでは、日常的によく使うGitコマンドをわかりやすくまとめてみました。これらのコマンドは、開発の効率を上げるのに役立ちます。

push

変更をプッシュした後に前の状態に戻す

プッシュ後に「あ、間違えた！」と思ったことはありませんか？以下のコマンドで、特定のコミットに戻って再度プッシュできます。

git log --oneline  // コミットハッシュを取得
git reset --hard <commit-hash>  // 特定のコミットハッシュに戻る
git push origin <branch-name> --force  // 強制的にリモートにプッシュ

クローン後、新しいリポジトリにpushする

既存のリポジトリをクローンして、新しいリポジトリにプッシュする方法です。

git remote set-url origin <新しいリポジトリのURL>
git remote -v
git branch -M main
git push -u origin main

commit

コミットを消す

コミットを取り消したい場合はresetコマンドを使います。取り消すコミットを確認するためにlogコマンドとセットで使われることが多いです。

git log --oneline
git reset オプション コミットID

# オプション
–soft
コミットされていない変更として残ります。
主に「コミットの内容を変更したい」時に使います。

–hard
こちらのオプションでは変更も全て削除されます。
「途中まで対応していたが結局対応不要になった」時などに使います。

他にもrevertコマンドがあります。

git revert コミットID

最後のcommitの状態に戻す

作業ディレクトリの変更を取り消したい場合は、以下のコマンドが便利です。

git checkout .  // 直前の状態に戻す
git checkout <ファイル名>  // 特定のファイルの変更を取り消す

プッシュしていないコミットを一覧表示

プッシュ前のコミットを確認するには、このコマンドを使います。

git log @{u}..

merge

マージを削除する

マージを取り消し、最初のmergeコマンドを実行する前の状態に戻ります。

git merge --abort

他のブランチを、mainブランチと同じ状態にする

特定のブランチをmainブランチと同期させたい場合は、以下のようにします。

git fetch origin
git checkout ブランチ名
git merge origin/main

リモートの特定ブランチから、ローカルの特定のブランチへ変更を取り込む方法
git fetch origin
git cehckout 反映させたいブランチ
git merge origin/feature/Issues_#16

リモート

リモート上の、ファイル名変更

リモートリポジトリ上でファイル名を変更する方法です。

git mv 古いファイル名 新しいファイル名
// このコマンドは以下の3つのコマンドと同じ意味を持つ
mv 古いファイル名 新しいファイル名
git rm 古いファイル名
git add 新しいファイル名

リモート上の、ファイルを削除

リモートリポジトリからファイルを削除する方法です。

git rm  // ワークツリーとローカルリポジトリの両方から削除
git rm --cached ファイル名  // ローカルリポジトリからのみ削除
git rm -r ディレクトリ名  // ディレクトリごと削除

リモートのリポジトリ名を変更した時、ローカル環境のリポジトリ名も変更

リモートリポジトリのURLが変更された場合、ローカルリポジトリのURLも更新する必要があります。

git remote set-url origin 新しいリポジトリURL

おわり

これらのコマンドは、日々の開発作業をスムーズに進めるために非常に役立ちます。Gitのコマンドは多岐にわたりますが、これらは特に頻繁に使われるものです。適切に使いこなすことで、開発の効率が大きく向上します。

The post Gitのよく使うコマンドまとめ：日常開発で役立つコマンド集 first appeared on AichiLog.

今回は、FlutterプロジェクトにCommitizenを導入する手順をわかりやすく説明します。

はじめに

FlutterプロジェクトでCommitizenを導入するには、プロジェクトのGitリポジトリにCommitizenを統合する必要があります。

ただし、Flutter自体はDartを使用しており、Node.jsやnpmとは直接関連していません。そのため、Commitizenを導入するにはNode.js環境が必要です。

以下はFlutterプロジェクトにCommitizenを導入する手順です。

前提条件

• Node.jsがインストールされていることを確認してください。
• Gitがインストールされていることを確認してください。

導入手順

1. プロジェクトディレクトリに移動

Flutterプロジェクトのルートディレクトリに移動します。

2. Commitizenをローカルにインストール

Node.jsのプロジェクトとして初期化するために、以下のコマンドを実行します（まだpackage.jsonがない場合）。

 npm init -y

次に、Commitizenを開発依存関係としてインストールします。

npm install --save-dev commitizen

3. Commitizenを初期化

npx commitizen init cz-conventional-changelog --save-dev --save-exact 

これにより、cz-conventional-changelogアダプタがプロジェクトに追加され、package.jsonに設定が保存されます。

4. コミットスクリプトをpackage.jsonに追加（オプション）

package.jsonにコミットスクリプトを追加することで、npm run commitを使用してCommitizenを起動できます。

{
  "scripts": {
    "commit": "cz"
  }
}

こちらで、下記のコードも追加することで、commitizenを日本語で利用することができます。

 "config": { 
    "commitizen": { 
       "path": "cz-conventional-changelog-ja" 
  } 
}

5. コミットの実行

これでセットアップは完了です。

コミットを行う際には、通常のgit commitの代わりにnpx czまたはnpm run commit（スクリプトを追加した場合）を使用します。

注意点

• CommitizenはFlutterのDartコードに直接関与しません。これはGitコミットメッセージの標準化のためのツールです。
• FlutterプロジェクトにNode.js関連のファイル（package.json、node_modulesフォルダなど）が追加されるため、これらを.gitignoreに追加することを検討してください（もし必要であれば）。

まとめ

Commitizenを導入することで、Flutterプロジェクトのコミットメッセージの一貫性と可読性が向上します。チームでの開発がスムーズになるため、ぜひ試してみてください。

「Kindle Unlimited」が2ヶ月99円！

Amazonの読み放題サービス「Kindle Unlimited」が、2ヶ月99円で利用できるキャンペーンが実施中。通常は1ヶ月980円なので、2ヶ月で1,861円もお得になる大チャンス!!（表示される特別プランの金額が異なる場合があります）
ビジネス書・実用書・小説・マンガなど読み放題のジャンルは多岐にわたるのできっとあなたの読みたい本が見つかります！
「あなたへの特別プラン 2ヶ月99円キャンペーン」は公式サイトにて本キャンペーンが表示されたユーザーのみ利用できるので、まずは下のボタンからチェックしてみましょう！

キャンペーンの確認はこちらから

The post 【Flutter】Flutterプロジェクト内に、commitizenを導入する方法 first appeared on AichiLog.