Effectivedjango.comのDjangoに関する記事の翻訳を紹介します。 このフレームワークを勉強しているときにこのサイトに出会いました。 このリソースに投稿された情報は役に立つように思えましたが、ロシア語への翻訳がどこにも見つからなかったため、この善行を自分で行うことにしました。 この一連の記事は、Djangoを学習するための最初のステップのみを行うWeb開発者にとって役立つと思います。

---

目次

• はじめに
• 効果的なDjango。 ガイド
  
  
  • 第1章はじめに
  • 第2章モデルの使用
  • 第3章パフォーマンスの作成
  • 第4章静的リソースの使用
  • 第5章高度な基本ビュー
  • 第6章フォームの基本
  • 第7章関連モデル
  • 第8章認証および承認処理
• Djangoでのテスト
• ミドルウェアについて
• データベースとモデル
• クラスビュー（CBV）
• フォーム

はじめに⇧

Djangoは人気のある強力なPythonフレームワークです。 多くの「 バッテリー 」があり、 すぐに開発を開始できます。 ただし、このパワーはすべて、動作するように見える基本コードを作成できることを意味します。 では、Effective Djangoの意味は何ですか？ Effective Djangoとは、記述されたコードが接続され 、 テスト可能でスケーラブルな方法でDjangoを使用することを意味します。 これらの単語はそれぞれ何を意味しますか？



「 接続された」コードとは、1つのことだけを実行することに焦点を当てたコードです。 これは、関数またはメソッドを作成するときに、作成したコードが1つのことを実行し、適切に実行する必要があることを意味します。



これは、 テスト可能なコードの作成に直接関係します 。多くのことを行うコードは、テストするのが難しすぎることがよくあります。 「さて、このコードは複雑すぎてテストを書くことができません-努力するだけの価値はありません」-これは単純化に戻って焦点を当てる合図です。 テストされたコードは、そのためのテストを簡単に書くことができるようなコードです。 問題が見つけやすいコード。



最後に、 スケーラブルなコードを記述します 。 これは、実行という観点でスケーリングするだけでなく、チームとチームの理解という観点で増大させることを意味します。 十分にテストされたアプリケーションは、他の人が理解しやすく（また、変更しやすい）、新しいエンジニアを追加してアプリケーションを改善する絶好の機会を意味します。



私の目標は、これらの原則の重要性をあなたに納得させ、それに従って、より堅牢なDjangoアプリケーションを構築する方法の例を提供することです。 連絡先管理アプリケーションの構築プロセスを経て、使用するソリューションとテスト戦略について説明します。



これらの文書は、PyCon 2012、PyOhio 2012、PyCon 2013、およびEventbrite Web開発用に作成されたメモと例の組み合わせです。 私はまだそれらを1つのドキュメントにまとめる作業を行っていますが、それらが役立つことを願っています。



このチュートリアルのサンプルコードはgithubで入手できます。 nathan@yergler.netにフィードバック、提案、質問を送信できます。

このドキュメントは、 WebサイトおよびPDFおよびEPub形式で入手できます 。



このガイドのビデオは、 YouTubeの PyConから見ることができます 。

第1章はじめに⇧

1.1。 開発環境

開発環境について話すとき、留意すべき3つの重要な事実があります： 分離 、 予定、および類似性 。 それらのそれぞれは重要であり、それらはすべて協調して互いに対話します。



分離とは、環境外にインストールされたツールやパッケージを誤って使用できないことを意味します。 これは、Cで記述された拡張機能を備えたPythonパッケージに似たものでこれが発生する場合に特に重要です。システムレベルでインストールされたものを使用し、それを知らない場合、コードをデプロイまたは配布すると、意図したとおりに機能しません。 virtualenvのようなツールは、隔離された環境のようなものを作成するのに役立ちます。



依存関係のどのバージョンに依存しているかが確実であり、システム環境を確実に再現できる場合、環境は事前定義されています。



最後に、本番または開発サーバー環境との類似性は、同じオペレーティングシステムがどこにでもインストールされ（おそらく同じリリースでも ）、同じツールを使用して開発環境を構成し、本番環境を構成することを意味します。 これは必ずしも必要ではありませんが、大規模で複雑なソフトウェアを構築している場合、「バトル」サーバーで見られるすべての問題が開発環境で再現可能であることを確認するために、類似性が役立ちます。 また、 類似性 によりコードの範囲が制限されます。

1.1.1。 分離

• 不明な依存関係や不明なバージョンの使用を避けたい。
• virtualenvは、システムサイトパッケージを使用せずにプロジェクトで作業する簡単な方法を提供します。

1.1.2。 予定

• 宛先は、依存関係管理を意味します。
• ツールの1つを選択し、開発中と「バトル」サーバーの両方で使用します。
  
  
  • pipおよび特別な依存関係ファイル 。
  • ビルドアウト
  • setup.py
    
    
    
    install-requires 。
• 依存関係の正確なバージョンを決定します。

PyPIパッケージバージョンまたは特定のリビジョン（gitのSHA、Subversionのリビジョン番号など）を使用してバージョンを特定できます。 これにより、テスト時に使用するのとまったく同じパッケージバージョンを取得できます。

1.1.3。 類似性

• アプリケーションをデプロイする環境と同様の環境で作業し、問題の検出を試みます。
• 追加のサービスを必要とするものを開発している場合、類似性はさらに重要になります。
• Vagrantは、日常環境とは別の環境を簡単に作成できる仮想マシン管理ツールです。

1.2。 環境をカスタマイズする

1.2.1。 きれいなワークスペースを作成する

翻訳者注：

最初に、作業するディレクトリを作成します（ tutorial



）：

 ~$ mkdir tutorial ~$ cd tutorial ~/tutorial$ mkdir venv project
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

venv



ディレクトリには仮想環境が含まれ、 project



ディレクトリにはDjangoプロジェクトが含まれます

 ~/tutorial$ virtualenv --prompt="(venv:tutorial)" ./venv/ New python executable in ./venv/bin/python Installing setuptools............done. Installing pip...............done. ~/tutorial$ source ./venv/bin/activate (venv:tutorial)~/tutorial$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1.2.2。 依存関係ファイルの作成

tutorial



ディレクトリに、1行（依存関係）を含むrequirements.txt



ファイルを作成しrequirements.txt



。

 Django==1.6.7
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

翻訳者注：

Djangoの最新バージョン（翻訳を書いている時点で1.7）を使用する場合Django==1.6.7



の行の代わりに、 Django==1.6.7



利用可能な最新バージョンをインストールします。

1.2.3。 依存関係のインストール

そして、 pipを使用して依存関係をインストールできます。

 (venv:tutorial)~/tutorial$ pip install -U -r requirements.txt Downloadping/unpacking Django==1.6.7 (from -r requirements.txt (line 1)) Downloading Django-1.6.7.tar.gz (6.6MB): 6.6MB downloaded Running setup.py egg_info for package Django warning: no previously-included files matching '__pycache__' found under directory '*' warning: no previously-included files matching '*.py[co]' found under directory '*' Installing collected packages: Django Running setup.py install for Django changing mode of build/scripts-2.7/django-admin.py from 644 to 755 warning: no previously-included files matching '__pycache__' found under directory '*' warning: no previously-included files matching '*.py[co]' found under directory '*' changing mode of /home/nathan/p/edt/bin/django-admin.py to 755 Successfully installed Django Cleaning up...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1.3。 Djangoプロジェクトの開始

建物が建設中の場合、建設が完了する前に構造を維持するために足場がよく使用されます。 足場は一時的なものでも、建物の基礎の一部として機能するものでもかまいませんが、それにもかかわらず、開始したばかりのときにはある程度のサポートを提供します。



Djangoは、多くのWebフレームワークと同様に、開発用の足場を提供します。 これは、決定を行い、コードの開始点を提供することで行われます。これにより、HTTPリクエストの解析方法ではなく、解決しようとしている問題に集中することができます。 Djangoは、HTTPでの作業とファイルシステムでの作業の両方に足場を提供します。



HTTP足場は、たとえば、HTTP要求をPython言語オブジェクトに変換するなどの制御を行い、サーバー側の応答をより簡単に作成するためのツールも提供します。 ファイルシステムの足場は異なります。これは、コードを整理するための一連の規則です。 エンジニアは、コードがどのように編成されているかを（仮に）すでに理解しているため、これらの規則により、プロジェクトに新しいエンジニアを簡単に追加できます。 Djangoの観点から見ると、 プロジェクトは最終製品であり、1つ以上のアプリケーションをそれ自体の中に組み合わせます。 Django 1.4では、プロジェクトとアプリケーションをディスクに配置する方法が変更され、さまざまなプロジェクトでアプリケーションを簡単に切断および再利用できるようになりました。

1.3.1。 プロジェクト作成

Djangoは、 django-admin.py



スクリプトをシステムにインストールして、scaffoldタスクを処理します。 プロジェクトファイルを作成するには、 startproject



タスクを使用します。 プロジェクトの名前と、プロジェクトを配置するディレクトリの名前を決定します。 すでに隔離された環境にいるので、次のように書くことができます。

翻訳者注：

ディレクトリを変更します~/tutorial/project/



そして、将来はこのディレクトリからのみ動作します（ $



は~/tutorial/project/$



を意味します）：

 (venv:tutorial)~/tutorial/$ cd project
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 (venv:tutorial)$ django-admin.py startproject addressbook .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作成されたプロジェクトの構造は次のとおりです

 manage.py ./addressbook __init__.py settings.py urls.py wsgi.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1.3.2。 プロジェクトの足場

• manage.py
  
  
  
  - django-admin
  
  
  
  スクリプトへのリンクですが、そこから設定を読み取り、必要に応じて管理するために、プロジェクトを指す定義済みの環境変数を使用します。
• settings.py
  
  
  
  ここにプロジェクトの設定があります。 ファイルにはすでにいくつかの適切な設定が含まれていますが、データベースは指定されていません。
• urls.py
  
  
  
  マッピング（表示）表現用のURLが含まれます。これについては後の章で詳細に説明します。
• wsgi.py
  
  
  
  は、アプリケーションのWSGI ラッパーです。 このファイルは、Django開発サーバーと、場合によっては「戦闘」サーバー上のmod_wsgi
  
  
  
  、 uwsgi
  
  
  
  などの他のコンテナーによって使用されます。

1.3.3。 アプリケーション作成

 (venv:tutorial)$ python ./manage.py startapp contacts
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作成されたアプリケーションの構造は次のとおりです。

 ./contacts __init__.py models.py tests.py views.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• Django 1.4以降、アプリケーションはプロジェクトパッケージ内でホストされます。 これは、特に「戦闘」サーバーにプロジェクトを展開するときが来ると、すばらしい改善です。
• models.py
  
  
  
  は、アプリケーションのDjango ORMモデルが含まれます。
• views.py
  
  
  
  には、ビューのコードが含まれます。
• tests.py
  
  
  
  には、作成した単体テストと統合テストが含まれます。
• Django 1.7： admin.py
  
  
  
  には管理インターフェースのモデルが含まれます。
• Django 1.7： migrations/
  
  
  
  移行ファイルを含む

翻訳者注：

現在、 ~/tutorial/



ディレクトリには、依存関係ファイル（ requirements.txt



）、仮想環境のディレクトリ（ venv/



）、1つのプロジェクト（ project/addressbook



）、1つのアプリケーション（ project/contacts



）が含まれており、次の内容が含まれています：

 ~/tutorial/ requirements.txt venv/ ... project/ manage.py addressbook/ __init__.py settings.py urls.py wsgi.py contacts/ __init__.py models.py tests.py views.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

第2章モデルの使用⇧

2.1。 データベース構成

Djangoは、すぐに使用できるMySQL、PostgreSQL、SQLite3、およびOracleをサポートしています。 SQLite3はバージョン2.5以降、Pythonの一部であるため、プロジェクトで使用します（簡単にするため）。 たとえば、MySQLを使用する場合は、 mysql-pythonをrequirements.txt



に追加する必要がありrequirements.txt



。



SQLiteをデータベースとして使用するには、 addressbook/settings.py



ファイルのDATABASES



定義を編集します。 settings.pyファイルには、プロジェクトのDjango設定が含まれています。 指定する必要があるいくつかの設定（たとえば、 DATABASES



と、その他のオプション設定があります。 Djangoは、プロジェクトを生成するときにいくつかの設定を自動的に設定します。 ドキュメントには、 設定の完全なリストが含まれています 。 さらに、必要に応じて独自の設定を追加できます。



SQLiteを使用するには、エンジン（ ENGINE



）とデータベース名（ NAME



）を指定する必要があります。 SQLiteは、データベース名をデータベースのファイル名として解釈します。

 DATABASES = { 'defaults': { 'ENGINE': 'django.db.backends.sqlite3,' # 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. 'NAME': os.path.join(BASE_DIR, 'address.db'), 'USER': '', # Not used with sqlite3. 'PASSWORD': '', # Not used with sqlite3. 'HOST': '', # Set to empty string for localhost. Not used with sqlite3. 'PORT': '', # Set to empty string for default. Not used with sqlite3. } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベースエンジンは、Pythonオブジェクトへの直接参照ではなく、文字列で示されることに注意してください。 これは、サードパーティの影響を引き起こさずに設定ファイルを簡単にインポートする必要があるためです。 このファイルにはインポート呼び出しを追加しないでください。



設定ファイルを直接インポートする必要はほとんどありません。Djangoが設定ファイルをインポートし、設定をdjango.conf.settings



として利用可能にします。 通常、 django.conf



から設定をインポートします。

 from django.conf import settings
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2.2。 モデル作成

Djangoモデルは（大まかに）データベーステーブルを表示し、ビジネスロジックをカプセル化する場所を提供します。 すべてのモデルは、基本クラスModelの子孫であり、定義フィールドが含まれています。 contacts/models.py



アプリケーションの簡単なContacts



モデルを作成しましょう：

 from django.db import models class Contact(models.Model): first_name = models.CharField( max_length=255, ) last_name = models.CharField( max_length=255, ) email = models.EmailField() def __str__(self): return ' '.join([ self.first_name, self.last_name, ])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Djangoは、データ型とさまざまな検証ルールを表示するためのフィールドセットを提供します。 たとえば、使用したEmailField



はCharField



型の列へのマッピングですが、データ検証を追加します。



モデルを作成したら、データベースに新しいテーブルを追加する必要があります。 Django syncdb



は、インストールされたモデルを調べて、必要に応じてそれらのテーブルを作成します。

翻訳者注：

Djangoは管理者のスーパーユーザーを作成することを提案します。これはデフォルトでこのバージョンに含まれています。 彼の申し出を利用してください。

翻訳者注：

Django 1.7以降、ネイティブ移行サポートがフレームワークに追加され、 syncdb



廃止されました。 そのため、 syncdb



代わりにmigrate



syncdb



を使用するように親切にしてください。

 (venv:tutorial)$ python ./manage.py syncdb Creating tables ... Creating table django_admin_log Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table auth_user_groups Creating table auth_user_user_permissions Creating table auth_user Creating table django_content_type Creating table django_session You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): yes Username (leave blank to use 'bjakushka'): Email address: Password: Password (again): Superuser created successfully. Installing custom SQL ... installing indexes ... Installed 0 object(s) from 0 fixture(s) (venv:tutorial)$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

翻訳者注：

Djangoバージョン1.7以降を使用する場合、出力は次のようになります。

 (venv:tutorial)$ python ./manage.py migrate Opperation to perform: Apply all migrations: admin, contenttypes, auth, sessions Running migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying sessions.0001_initial... OK (venv:tutorial)$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、連絡先表はどこにもありません。 この理由は、アプリケーションを使用するようプロジェクトに伝える必要があるためです。



INSTALLED_APPS



設定には、プロジェクトで使用されるアプリケーションのリストが含まれています。 このリストには、Pythonパッケージを表示する文字列が含まれています。 Djangoは、指定された各パッケージをインポートし、 models



モジュールを監視します。 contacts



アプリケーションをプロジェクト設定（ addressbook/settings.py



）に追加しましょう：

 INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'contacts', )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、 syncdb



再度実行しsyncdb



。

翻訳者注：

Djangoバージョン1.7以降では、作成された移行を適用するために、 makemigrations



コマンドを実行し、モデルの変更に基づいて移行を作成し、 makemigrations



コマンドを実行する必要があります。

 (venv:tutorial)$ python ./manage.py syncdb Creating tables ... Creating table contacts_contact Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) (venv:tutorial)$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

翻訳者注：

Django 1.7以降の出力：

 (venv:tutorial)$ python ./manage.py makemigrations Migrations for 'contacts': 0001_initial.py: - Create model Contact (venv:tutorial)$ python ./manage.py migrate Opperation to perform: Apply all migrations: admin, contenttypes, sessions, auth, contacts Running migrations: Applying contacts.0001_initial... OK (venv:tutorial)$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Djangoはcontacts_contact



というテーブルを作成することに注意してください。デフォルトでは、Dj angoはアプリケーション名とモデル名の組み合わせを使用してテーブル名を与えます。 これは、 メタモデルオプションで変更できます。

2.3。 モデルの相互作用

モデルがデータベースと同期されたので、対話型シェルを使用してモデルと対話できます。

 (venv:tutorial)$ python ./manage.py shell Python 2.7.3 (default, Mar 14 2014, 11:57:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from contacts.models import Contact >>> Contact.objects.all() [] >>> Contact.objects.create(first_name='Nathan', last_name='Yergler') <Contact: Nathan Yergler> >>> Contact.objects.all() [<Contact: Nathan Yergler>] >>> nathan = Contact.objects.get(first_name='Nathan') >>> nathan <Contact: Nathan Yergler> >>> print nathan Nathan Yergler >>> nathan.id 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここではいくつかの新しいピースが使用されました。 まず、 manage.py shell



コマンドは、Djangoの正しいパスを使用してインタラクティブなPython manage.py shell



を起動します。 Pythonインタープリターを起動してアプリケーションをインポートしようとすると、使用する設定がDjangoにわからず、モデルインスタンスをデータベースにマップできないため、例外がスローされます。



次に、モデルのobjects



プロパティがここで使用されました。 これはモデルマネージャーです。 そのため、モデルの1つのインスタンスがデータベース内の行のアナロジーである場合、モデルマネージャーはテーブルのアナロジーです。 デフォルトでは、モデルマネージャーはクエリ機能を提供し、カスタマイズできます。 all()



、 filter()



またはマネージャー自体を呼び出すと、 QuerySet



オブジェクトが返されます。 QuerySet



は反復可能なオブジェクトであり、必要に応じてデータベースからデータをロードします。



そして最後の-上記では、 id



というフィールドを使用しましたが、これはモデルでは定義していません。 Djangoは、このフィールドをモデルの主キーとして追加しますが、どのフィールドが主キーになるかを自分で決定していない場合のみです。

2.4。 テストを書く

このモデルでは__str__



1つのメソッドを定義しているので、テストを作成します。 __str__



メソッドはごく少数の場所でのみ使用され、 可能性としてはエンドユーザーに完全に表示されます 。 この方法のテストを書く価値はありますが、その仕組みを理解しています。 Djangoはアプリケーションを作成したときにtests.py



ファイルを作成したため、このファイルに最初のテストであるcontacts



アプリケーションを追加します。

 from django.test import TestCase from contacts.models import Contact class ContactTests(TestCase): """Contact model tests.""" def test_str(self): contact = Contact(first_name='John', last_name='Smith') self.assertEquals( str(contact), 'John Smith', )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

manage.py test



コマンドを使用して、アプリケーションのテストを実行できます。

 (venv:tutorial)$ python ./manage.py test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを実行すると、約420のテストが完了したことがわかります。 1つしか書いていないので、これは驚くべきことです。 これは、デフォルトで、インストールされているすべてのアプリケーションに対してDjangoがテストを実行するために発生しました。 contacts



アプリケーションをプロジェクトに追加すると、デフォルトでいくつかのDjango組み込みアプリケーションが追加されていることがわかります。 そこからさらに419のテストが行​​われました。

翻訳者注：

私たちの場合（Djangoバージョン1.6.7を使用している場合）、前の段落はやや時代遅れです：実行するテストは1つだけです-作成したものです。 コマンドの出力は次のようになります。

特定のアプリケーションに対してテストを実行する場合-コマンドでアプリケーションの名前を指定します。

 (venv:tutorial)$ python manage.py test contacts Creating test database for alias 'default'... . ---------------------------------------------------------------------- Ran 1 tests in 0.001s OK Destroying test database for alias 'default'... (venv:tutorial)$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に進む前に注意すべきもう1つの興味深い点は、出力の最初と最後の行です。 Destroying test database



Creating test database



Destroying test database



です。 一部のテストではデータベースへのアクセスが必要です。テストデータを「実際の」ものと干渉させたくない（さまざまな理由で、少なくとも事前決定ではありません）ため、Djangoはテストを実行する前にテストデータベースを作成してくれます。 基本的に、新しいデータベースが作成され、その後、 syncdb



開始されます。 テストクラスがTestCase



クラスの下位クラスである場合（私たちのものと同様）、Djangoは各テストの実行後にデータをデフォルト値にリセットするため、テストの1つの変更が他のテストに影響を与えません。

2.5。 まとめ

• モデルはテーブル内のフィールドを定義し、ビジネスロジックを含みます。
• syncdb
  
  
  
  は、モデルからデータベースにテーブルを作成します。 Djangoバージョン1.7以降では、 syncdb
  
  
  
  代わりに、最初にmakemigrations
  
  
  
  コマンドを使用して移行を作成し、次にmigrate
  
  
  
  コマンドを使用してデータベースに変更を加える必要があります。
• モデルマネージャーを使用すると、インスタンスのコレクション（クエリ、作成など）を処理できます。
• モデルに追加したメソッドの単体テストを作成します。
• test
  
  
  
  制御コマンドは、実行する単体テストを実行します。

翻訳者注：

まだ空のアプリケーションをテストするには、次のコマンドを実行する必要があります。

 (venv:tutorial)$ python ./manage.py runserver 0.0.0.0:8080
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、組み込みサーバーが起動し、その機能はDjangoから親切に提供されます。 runserver



後のパラメーターには、実行中のサーバーがリッスンするip-addressとportが指定されています。 この場合、サーバーはポート8080にアクセスするときにすべてのIPアドレスからの要求を受け入れます。



私は、内部IPが192.168.1.51のホームサーバーを開発に使用しています。 したがって、ブラウザで開発サーバーの結果を確認するには、アドレスhttp://192.168.1.51:8080/にアクセスします 。 サーバーのアドレスを置き換える必要があります。

---

残りの章の翻訳を続ける必要があると思いますか？ 翻訳は役に立ちましたか？

コメントで建設的な批判ができればうれしいです。

翻訳の誤りや不正確さについては、個人的なメッセージでお知らせください。



投稿の冒頭で使用された画像は、ユーザーMaGIc2laNTernの 画像のバリエーションとして作成されました