DEV Community: Takenoko Tech LLC.

Next.js（TypeScript）のプロジェクト作成 ESLint+Prettier（＠2022-06-29）

niwoshi — Thu, 14 Jul 2022 01:24:46 +0000

ちょっと色々変わってないか確認がてらプロジェクトの作成をまとめなおします。

この辺は気がついたら推奨設定が変わってたりするのでちょいちょい見直したいところです。

プロジェクトの作成

nodeがインストールされた環境を想定しています。まずはプロジェクトを作成しておきます。

npx create-next-app [プロジェクト名] --typescript

必要最低限は上記のコマンドで準備されます。
個人的に頻繁に触りそうなファイル群はsrcというディレクトリにいれときたいので、pages、stylesはsrcというディレクトリを作成して入れておきます。
Next.jsではデフォルトでsrcというディレクトリが存在すればそちらをpagesが含まれているディレクトリとして認識してくれるので、これで動作します。
とはいえ、絶対パスに"@"を利用したい（いちいちパスを記載するのが面倒）ので、tsconfig.jsonにbaseUrlの設定を追加します。

    "incremental": true,
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }

これで相対パスを省略して記載できます。

一応動作を確認しておきたいので、src/pages/index.tsxの4行目を下記のように変更してみます。

import styles from '@/styles/Home.module.css'

動作チェックです。

yarn dev

問題無く表示されればOKです。

Voltaでnodeとyarnのバージョン固定

自分はnodeのバージョン管理にVoltaを利用しています。

ある程度よしなにしてくれるのでほっといてもいい気はしますが、トラブルに巻き込まれた際に面倒になるのでnodeとyarnのバージョンをプロジェクトで固定しておきます。

volta pin node@16
volta pin yarn@1.22

ESLint+Prettier

ESLint

create-next-appで作成していれば必要最低限の準備は既に出来ています。
試しに、.eslintrc.jsonを次のように書き換えて、セミコロンの警告を出します。

{
  "extends": "next/core-web-vitals",
  "rules": {
    "semi": ["error", "never", {"beforeStatementContinuationChars": "never"}],
    "semi-spacing": ["error", {"after": true, "before": false}],
    "semi-style": ["error", "first"],
    "no-extra-semi": "error",
    "no-unexpected-multiline": "error",
    "no-unreachable": "error"
  }
}

index.tsxなどのどこかにセミコロンを記入して

yarn lint

すると警告が表示されると思います。
この時点で

yarn lint --fix

で修正まで入るようになります。

Prettier

整形は例にならってPrettierで行います。よって、先ほど追加したセミコロンのルールは削除してしまって構いません。（ESLint -> Prettierの順番で実行しようと考えているのでどうせ上書きされる）
PrettierとESLintのプラグインをインストールしておきます。

yarn add -D -E prettier
yarn add -D eslint-config-prettier

eslint-config-prettierの設定を適応させるために、.eslintrc.jsonを書き換えておきます。

{
  "extends": ["next/core-web-vitals", "prettier"],
  "rules": {
    "semi": ["error", "never", {"beforeStatementContinuationChars": "never"}],
    "semi-spacing": ["error", {"after": true, "before": false}],
    "semi-style": ["error", "first"],
    "no-extra-semi": "error",
    "no-unexpected-multiline": "error",
    "no-unreachable": "error"
  }
}

package.jsonに書いてもいいんですが、既に.eslintrc.jsonも生成されてますので、.prettierrc.jsonを作成してそこにPrettierの設定を書いておきます。
とりあえず自分の必要最低限のモノだけ書いています。

{
  "trailingComma": "all",
  "tabWidth": 2,
  "semi": false,
  "singleQuote": true,
  "jsxSingleQuote": true
}

Prettierでプロジェクト全体を整形したい場合用に、package.jsonのscriptsにformatというコマンドを追加しておきます。

    "format": "prettier --write ./**/*.{js,jsx,ts,tsx,json,css} --ignore-path .gitignore"

とりあえず上記までで

yarn lint --fix
yarn format

で全体を解析＋フォーマットできるようになりました。
ここから先はお好みで、ローカルで解析やテストを回すなら「husky+lint-staged」、コミット先でやるなら「Github ActionsでESLint+Prettier+テスト」という構成などが考えられると思います。

参考

https://qiita.com/mysticatea/items/9da94240f29ea516ae87

btrfsのRAID構成をオンラインで変更する

k11o — Wed, 06 Jul 2022 12:23:05 +0000

今まで btrfs の RAID 5 で3台の HDD を束ねて使っていましたが、容量の不足もあったので3台の HDD を追加し RAID 6 運用に変更した際の忘備録。これがオンラインで出来るのはありがたいです。

もとの状態

konota@storage:/data$ sudo btrfs filesystem show
Label: none  uuid: 71cdbe11-5102-448d-9aac-2dda635edf30
        Total devices 1 FS bytes used 8.57GiB
        devid    1 size 58.09GiB used 11.06GiB path /dev/mapper/ubuntu--vg-ubuntu--lv

Label: '/data'  uuid: 27c4fe5d-89ec-4edd-853b-82a13ce4febe
        Total devices 3 FS bytes used 3.01TiB
        devid    1 size 2.73TiB used 1.54TiB path /dev/sde
        devid    2 size 2.73TiB used 1.54TiB path /dev/sdd
        devid    3 size 2.73TiB used 1.54TiB path /dev/sdf

新しいHDDを追加して、balance実行時にオプションでdataとmetadataを変換します。追加前に mkfs.btrfs でフォーマットを忘れずに。本来なら直前にbtrfs filesystem show コマンド等で追加状況を確認したほうがいいです。

konota@storage:~$ sudo btrfs device add /dev/sda /data
konota@storage:~$ sudo btrfs device add /dev/sdb /data
konota@storage:~$ sudo btrfs device add /dev/sdc /data
konota@storage:~$ sudo btrfs balance start -dconvert=raid6 -mconvert=raid6 /data
WARNING:

        RAID5/6 support has known problems and is strongly discouraged
        to be used besides testing or evaluation. It is recommended that
        you use one of the other RAID profiles.
        The operation will continue in 10 seconds.
        Use Ctrl-C to stop.
10 9 8 7 6 5 4 3 2 1

balance処理中は追加されたdeviceのusedが増加するのがわかります。

konota@storage:~$ sudo btrfs filesystem  show
[sudo] password for konota:
Label: none  uuid: 71cdbe11-5102-448d-9aac-2dda635edf30
        Total devices 1 FS bytes used 8.57GiB
        devid    1 size 58.09GiB used 11.06GiB path /dev/mapper/ubuntu--vg-ubuntu--lv

Label: '/data'  uuid: 27c4fe5d-89ec-4edd-853b-82a13ce4febe
        Total devices 6 FS bytes used 3.01TiB
        devid    1 size 2.73TiB used 1.54TiB path /dev/sde
        devid    2 size 2.73TiB used 1.54TiB path /dev/sdd
        devid    3 size 2.73TiB used 1.54TiB path /dev/sdf
        devid    4 size 2.73TiB used 17.27GiB path /dev/sda
        devid    5 size 2.73TiB used 17.27GiB path /dev/sdb
        devid    6 size 2.73TiB used 17.27GiB path /dev/sdc

balance処理中、Celeron G6900ですがtopはこのような状態です。この量の変換で一晩ほどかかりそうです。(現在進行系)

その後無事に変換が完了していることを確認しました。今回の場合、3台追加してRAID6にしたので各デバイスごとのusedは減少しました。

Djangoで既存モデルにForeignKeyなフィールドを追加する場合のMigrationについて

k11o — Tue, 03 May 2022 14:34:12 +0000

Djangoでは割と使い物になるMigration生成機能がありますが、既存モデルにForeignKeyでフィールドを追加する場合、当該フィールドがNOT NULL制約付きなため、Migration時に適当な初期値を渡す必要があります。

具体的にコードで書くと、下記のような変更を行った場面です。(Postモデルのデータをいくつか作成したものの、TagでPostをまとめたくなった、という想定)

既存コード

class Post(models.Model):
    text = models.TextField("本文",blank=False)

追加後

class Tag(models.Model):
    name = models.CharField("名前",max_length=10,blank=True)

class Post(models.Model):
    text = models.TextField("本文",blank=False)
    tag = models.ForeignKey(Tag,on_delete=CASCADE)

この場合既存データが存在するため、普通にMigrationでフィールドを追加、というのが難しくなります。
そこでTagモデルのデータを作りつつ、既存のPostについては全て一旦生成したTagに紐づけるようなMigrationを、一回のMigration生成で行う方法を考えてみます。

先程のコードの変更を行ったあとに manage.py makemigrations を実行すると、既存データにNOT NULLな列が追加されるからデフォルト値が必要だよ!どうする?みたいなプロンプトが出るので、one-off default値を渡すことにして適当な値を突っ込みます(本来ならここでPythonコードが書けるのでTagモデルのデータを作りつつその値を渡す…ということが出来るのかも知れませんが、私が試した限りでは実現出来ませんでした。)

そうすると下記のようなMigrationコードが生成されます。

class Migration(migrations.Migration):

    dependencies = [
        ('application', '0011_auto'),
    ]

    operations = [
        migrations.AddField(
            model_name='post',
            name='tag',
            field=models.ForeignKey(default=1, on_delete=django.db.models.deletion.CASCADE, to='application.tag'),
            preserve_default=False,
        ),
    ]

当然、このまま実行するとあまり良くない結果になるので、migrateコマンドは実行せずmigrationファイルを修正します。

処理の方針としては

NOT NULL制約無しで列を追加
Tagモデルのデータをとりあえず作り、既存データを紐づけるように更新
NOT NULL制約を付ける

という順序でやってます。

migrationsにはRunPythonというMigration中に関数を実行する機能があるのでこれを利用します。因みにこの機能はRollback用関数も定義出来るので中々強力です。

またRunPythonで呼び出す関数については、ドキュメントにある通り引数の apps及びschema_editorを利用してDBへの接続やModelの取得を行います。

これらを踏まえ、前述した処理の通りに、既存のPostを全てTag「日常日記」に紐づけるようなMigrationに修正したものが下記です。

def create_tag(apps, schema_editor):
    db_alias = schema_editor.connection.alias
    Tag = apps.get_model("application", "Tag")
    tag = Tag.objects.using(db_alias).create(name="日常日記")
    Post = apps.get_model("application", "Post")
    Post.objects.using(db_alias).update(tag=tag)

class Migration(migrations.Migration):

    dependencies = [
        ('application', '0011_auto'),
    ]

    operations = [
        migrations.AddField(
            model_name='post',
            name='tag',
            field=models.ForeignKey(null=True, on_delete=django.db.models.deletion.CASCADE, to='application.tag'),
            preserve_default=False,
        ),
        migrations.RunPython(create_tag),
        migrations.AlterField(
            model_name='post',
            name='tag',
            field=models.ForeignKey(null=False, on_delete=django.db.models.deletion.CASCADE, to='application.tag'),
            preserve_default=False,
        ),
    ]

これで一つのmigrationで既存データを破壊せずに外部キーを追加する事が出来ました。
ただもっとスマートな方法がある気がしていますので、ご存知の方は是非コメント欄で教えていただけるとありがたいです。

Django REST frameworkのユニットテスト

niwoshi — Thu, 20 Jan 2022 10:37:02 +0000

Django REST framework（以下DRF）のテストについて軽くまとめておきます。
一応前回の続きという事で進めて行きます。
正直Djangoのテストは慣れていないのでなにからやれば良いか試行錯誤している段階ではあります。

テストフォルダの作成

DRFの場合、テスト対象としてはアプリケーション毎にモデル、シリアライザ、ビューの3種類が考えられます。
startappで自動生成されるapiv1/tests.pyにテストを書いていってもいい気もしますが、上記3種のテストを1ファイルに書いてしまうと肥大化していくのは目に見えているので、上記を分離しておきます。
apiv1/testsフォルダを作成して

apiv1/tests/__init__.py
apiv1/tests/test_models.py
apiv1/tests/test_serializers.py
apiv1/tests/test_views.py

の用にテストファイルを作成します。（必要なものだけで大丈夫かと思います。）
__init__.pyは空ファイルで大丈夫です。ついでに

apiv1/tests.py

は削除しておきます。

ビューのテスト

今回はDRFのviewsetsをそのまま継承して利用しているだけなので、おそらくテストは不要だと思います。
とはいえ一応チュートリアル的な観点で試したいのでTodoの生成だけテストを書いておきます。apiv1/tests/test_views.pyを作成します。

from django.urls import reverse
from rest_framework.test import APITestCase


from todos.models import Todo


class TodoCreateTests(APITestCase):
    def test_create_success(self):
        params = {
            "title": "test_create_success",
        }
        url = reverse("apiv1:todos-list")
        response = self.client.post(url, params, format="json")

        self.assertEqual(Todo.objects.count(), 1)
        self.assertEqual(response.status_code, 201)
        todo = Todo.objects.get()
        expected_json_dict = {
            "id": str(todo.id),
            "title": todo.title,
            "checked": todo.checked,
        }
        self.assertJSONEqual(response.content, expected_json_dict)

    def test_create_bad_request(self):
        params = {
            "title": "",
        }
        url = reverse("apiv1:todos-list")
        response = self.client.post(url, params, format="json")

        self.assertEqual(Todo.objects.count(), 0)
        self.assertEqual(response.status_code, 400)

下記コマンドで全テストが捜索され実行されます。

python manage.py test

アプリケーションやクラスを指定して実行もできますが、ここでは割愛します。

シリアライザのテスト

シリアライザのテストは、実際のリクエストを受け入れる際のバリデーションと、レスポンスを返す時の出力内容を検証すれば大丈夫だと思います。引き続き、apiv1/tests/test_serializers.pyを作成します。

from django.test import TestCase

from todos.models import Todo
from ..serializers import TodoSerializer


class TodoSerializerTest(TestCase):
    def test_input_valid(self):
        input_data = {"title": "test_input_valid"}
        serializer = TodoSerializer(data=input_data)

        self.assertEqual(serializer.is_valid(), True)

    def test_input_invalid_if_title_is_blank(self):
        input_data = {"title": ""}
        serializer = TodoSerializer(data=input_data)

        self.assertEqual(serializer.is_valid(), False)
        self.assertCountEqual(serializer.errors.keys(), ["title"])
        self.assertCountEqual([x.code for x in serializer.errors["title"]], ["blank"])

    def test_output_data(self):
        todo = Todo.objects.create(
            title="test_output_data",
        )
        serializer = TodoSerializer(instance=todo)

        expected_data = {
            "id": str(todo.id),
            "title": todo.title,
            "checked": todo.checked,
        }
        self.assertDictEqual(serializer.data, expected_data)

とはいえ、先ほどのビューのテストで作成を検証していて、titleがブランクの時にエラーがでる処理を検証しているので少し被っている気もします。
上記の例で言えばシリアライザのテストのみでいいと思いますが、そもそもviewsetsを利用している場合は開発段階で十分テストされていると思うので、省略してしまっても大丈夫だと思います。

モデルのテスト

こちらは通常のDjangoでのテストと変わらないので割愛します。

参考

Django REST frameworkの初期セットアップ

niwoshi — Thu, 20 Jan 2022 10:36:45 +0000

Django REST framework（以下DRF）でバックエンドを構築する際の初期設定をメモ代わりに書いておきます。
（書かないと無限に忘れるので・・・）

プロジェクトの作成

プロジェクト名はtutorialとしておきます。
ディレクトリを作成して仮想環境(venv)が導入されている前提です。

まずはrequirements.txtに必要最低限のライブラリのみ書いておきます。
よく使うライブラリもこのタイミングで入れていいと思います。

django
djangorestframework

必要パッケージのインストール

pip install -r requirements.txt

Djangoプロジェクトの作成をコマンドで行います。
この辺は完全に好みだと思うのですが、プロジェクト名/プロジェクト名/settings.pyみたいにプロジェクト名が二重にネストするのがちょっと気持ち悪いので、この設定ファイルなどがあるディレクトリ名をconfigにするために、下記のようにDjangoプロジェクトを作成します。
仮想環境を入れたプロジェクトファイル下で下記のコマンドを実行します。

django-admin startproject config .

プロジェクト全体のディレクトリ構成は下記の様になります。

tutorial
├─ venv
├─ requirements.txt
├─ manage.py
└─ config
   ├─ __init__.py
   ├─ asgi.py
   ├─ settings.py
   ├─ urls.py
   └─ wsgi.py

機能的にはtutorial/tutorialになってもなんら問題無いのでこの辺は完全に好みです。むしろこっちの方が面倒。
動作チェックはDRFとして動いて欲しいので、適当なモデルを作成してから行います。

アプリケーションの追加

試しにTodoを管理するアプリケーションを想定して構築してみます。
DRFはAPIエンドポイントとして運用される想定なので、一応バージョニングを意識して

APIエンドポイント用のアプリケーション（ここではapiv1）
モデル用のアプリケーション（ここではtodos）

を分離しておきます。
manage.pyでアプリケーションを作成しておきます。

python manage.py startapp apiv1
python manage.py startapp todos

ここで初期設定もかねてconfig/settings.pyを編集します。

...

from pathlib import Path
from django.conf.locale.ja import formats as ja_formats

...

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "rest_framework",
    "apiv1.apps.Apiv1Config",
    "todos.apps.TodosConfig",
]

...

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

LANGUAGE_CODE = "ja"

TIME_ZONE = "Asia/Tokyo"

USE_I18N = True

USE_L10N = True

USE_TZ = True

ja_formats.DATE_FORMAT = "Y/m/d"
ja_formats.DATE_INPUT_FORMATS = ("%Y/%m/%d",)
ja_formats.DATETIME_FORMAT = "Y/m/d H:i:s"
ja_formats.DATETIME_INPUT_FORMATS = ("%Y-%m-%d %H:%M:%S",)

...

INSTALLED_APPSの追記は、Django 3.2からAutomatic AppConfig discoveryで不要になったと聞いたのですが、自分の環境では何故か管理画面にモデルが表示されないので追記しています。

モデルの作成

models.pyの編集

何はともあれモデルがないと始まりません。
Todoモデルtodos/models.pyを作成していきます。

import uuid
from django.db import models


class Todo(models.Model):
    class Meta:
        db_table = "todo"

    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    title = models.CharField(max_length=200)
    checked = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title

idをUUIDにしていますが、ここは好みです。（とはいえ、UUIDの方が推奨されそうですが・・・）

admin.pyの編集

モデルを作ったら管理画面で編集できる様にしておきたいです。
todos/admin.pyを編集します。

from django.contrib import admin

from .models import Todo


class TodoAdmin(admin.ModelAdmin):
    fields = ["title", "checked"]
    list_display = ("title", "checked", "id", "created_at", "updated_at")


admin.site.register(Todo, TodoAdmin)

一応管理画面を確認しておきたいので念のためDBを更新してからcreatesuperuserで管理ユーザーを作成しておきます。

python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser

ここまでやれば管理画面からモデルを操作できるので、動作に不安のある場合はこの辺で新規作成などしてみても良いと思うます。

シリアライザの作成

DRF特有の存在であるシリアライザを作成します。
これはAPIの機能なのでapiv1/serializers.pyに作成します。

from rest_framework import serializers

from todos.models import Todo


class TodoSerializer(serializers.ModelSerializer):
    class Meta:
        model = Todo
        fields = [
            "id",
            "title",
            "checked",
        ]

ビューの作成

API用のビューapiv1/views.pyを編集します。

from rest_framework import viewsets

from todos.models import Todo
from .serializers import TodoSerializer


class TodoViewSet(viewsets.ModelViewSet):
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer

ルーティングの設定

大体の機能は実装できたので、ルーティングの設定をしておきます。
まずはapiv1/urls.pyを作成します。

from django.urls import path, include
from rest_framework import routers

from . import views

router = routers.DefaultRouter()
router.register("todos", views.TodoViewSet, basename="todos")

app_name = "apiv1"
urlpatterns = [path("", include(router.urls))]

routerにtodosを登録する際にbasename="todos"と指定しているのは、django.urlsのreverse関数で逆引きする際にapiv1:todos-listとしたい為です。コレを指定していない場合はビューのquerysetに登録したモデルの名称が採用されてapiv1:todo-listと参照されてしまう様です。

今回はビューをModelViewSetで実装したのでルーティングが楽です。
あとはconfig/urls.pyを編集します。

from django.contrib import admin
from django.urls import path, include

urlpatterns = [path("admin/", admin.site.urls), path("api/v1/", include("apiv1.urls"))]

ここまでやれば、APIとしては実装完了です。

動作チェック

DRFはデバッグモードではブラウザ上で色々確認出来ます。
試しにアクセスしてみると、何もないリストが返却されているのが確認出来ると思います。

POST用のフォームもあるので、そちらから追加して見るもヨシ、cURLなどで追加して見るもヨシです。

おわり

上記だけでCRUD操作ができるAPIが構築でき、管理画面も使いやすいしカスタマイズしやすいのがDRFの良さだと思います。
本来であれば認証まわりも実装すると思いますが、今回は簡略化のため省きました。
実際に実装する場合はDRFの設定（settings.py）とビューでの設定などが必要になると思います。

参考

DjangoのClass-Based Viewで権限確認を行う

k11o — Fri, 12 Nov 2021 14:55:22 +0000

DjangoでClass-Based ViewによるDetailView等を実装している際に、そのViewへのアクセスの可否をカスタムで確認したい場合があると思います。
例えば下記の様なモデルのDetailViewにおいて、各ユーザー自分のデータしか見れないようにする、などと言った場面です。

class Memo(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)

path('memo/<int:pk>', views.MemoDetailView.as_view(),
         name='memo_detail'),

class MemoDetailView(DetailView):
    model = models.Memo

このままだと memo/2 のような適当な URL を入れることで誰でも閲覧可能になってしまいます。これを自分の Memo しか見れないようにします。

このような場面のためにテスト用のclassが用意されています。

class UserPassesTestMixin https://docs.djangoproject.com/ja/3.2/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin

test_func で OK/NG を Bool で返せば良いので、今回の場合だと下記のようなclassを作成し

class ObjectOwnerCheckMixin(UserPassesTestMixin):
    def test_func(self):
        login_user = self.request.user
        object_owner = self.get_object().user
        return login_user == object_owner

View側ではそれを継承すればOKです。

class MemoDetailView(ObjectOwnerCheckMixin,DetailView):
    model = models.Memo