1. ホーム
2. Playリリース
3. Play 2.3

§Play 2.3 移行ガイド

これはPlay 2.2からPlay 2.3に移行するためのガイドです。以前のバージョンのPlayから移行する必要がある場合は、まずPlay 2.2移行ガイドに従う必要があります。

§Activator

Play 2.3では、playコマンドがactivatorコマンドになりました。PlayはActivatorを使用するように更新されました。

§Activatorコマンド

playコマンドで使用可能だったすべての機能は、activatorコマンドでも引き続き使用できます。

• activator newは新しいプロジェクトを作成します。新しいアプリケーションの作成を参照してください。
• activatorはコンソールを実行します。Playコンソールの使用を参照してください。
• activator uiはWebユーザーインターフェースを起動する新しいコマンドです。

新しいactivatorコマンドと古いplayコマンドは、どちらもsbtのラッパーです。必要であれば、sbtコマンドを直接使用できます。ただし、sbtを使用すると、テンプレート（activator new）やWebユーザーインターフェース（activator ui）など、いくつかのActivator機能を利用できなくなります。sbtとActivatorの両方で、testやrunなどの通常のコンソールコマンドがすべてサポートされています。

§Activatorディストリビューション

Playは、Playのすべての依存関係を含むActivatorディストリビューションとして配布されます。このディストリビューションは、Playダウンロードページからダウンロードできます。

必要であれば、Activatorサイトから最小（1MB）バージョンのActivatorをダウンロードすることもできます。ダウンロードページの「mini」ディストリビューションを探してください。最小バージョンのActivatorは、必要な場合にのみ依存関係をダウンロードします。

Activatorはsbtのラッパーであるため、必要であれば、sbtを直接ダウンロードして使用することもできます。

§ビルドの変更

§sbt

Playはsbt 0.13.5を使用します。既存のプロジェクトを更新する場合は、project/build.propertiesファイルを次のように変更します。

sbt.version=0.13.5

§プラグインの変更

project/plugins.sbtでPlayプラグインのバージョンを変更します

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.XXX")

ここで2.3.XXXは、使用するPlayのバージョンです。

また、いくつかのsbt-webプラグインを追加する必要があります。以下のsbt-webセクションを参照してください。

§自動プラグインとプラグイン設定

sbt 0.13.5には、「自動プラグイン」という名前の新しい機能が搭載されています。

自動プラグインを使用すると、以前と同様に、projectフォルダー（通常はplugins.sbt）でsbtプラグインを宣言できます。ただし、変更されたのは、プラグインが他のプラグインの要件と、特定のビルドで有効にするトリガーを宣言できるようになったことです。自動プラグインの前は、ビルドに追加されたプラグインは常に利用可能でしたが、現在ではプラグインは特定のモジュールに対して選択的に有効になります。

これは、addSbtPluginを宣言しても、自動プラグイン機能を利用するプラグインには不十分な可能性があることを意味します。これは良いことです。プロジェクトのどのモジュールにどのプラグインを含めるかを、選択できるようになりました。たとえば、次のようになります。

lazy val root = (project in file(".")).enablePlugins(SbtWeb)

上記の例では、SbtWebがビルドのルートプロジェクトに追加されています。SbtWebの場合、有効になる他のプラグインがあります。たとえば、addSbtPluginを使用してsbt-less-pluginも追加した場合、SbtWebが有効になっているだけで有効になります。したがって、SbtWebは、そのカテゴリのプラグインの「ルート」プラグインです。

Play自体は、自動プラグインメカニズムを使用して追加されるようになりました。playJavaSettingsおよびplayScalaSettingsが使用されていたPlay 2.2で使用されていたメカニズムは削除されました。代わりに、次のいずれかを使用します。

lazy val root = (project in file(".")).enablePlugins(PlayJava)

または

lazy val root = (project in file(".")).enablePlugins(PlayScala)

以前にplay.Projectを使用していた場合（たとえば、Scalaプロジェクト）

object ApplicationBuild extends Build {

  val appName = "myproject"
  val appVersion = "1.0-SNAPSHOT"

  val appDependencies = Seq()

  val main = play.Project(appName, appVersion, appDependencies).settings(
  )

}

…その後、ネイティブsbtを使用して同様のアプローチを引き続き使用できます

object ApplicationBuild extends Build {

  val appName = "myproject"
  val appVersion = "1.0-SNAPSHOT"

  val appDependencies = Seq()

  val main = Project(appName, file(".")).enablePlugins(play.PlayScala).settings(
    version := appVersion,
    libraryDependencies ++= appDependencies
  )

}

上記のスタイルに移行することで、プラグインが有効になると設定が自動的にインポートされるようになりました。

Playによって提供されるキーは、PlayKeysオブジェクト内で参照する必要があります。たとえば、playVersionを参照するには、次のいずれかをインポートする必要があります。

import PlayKeys._

または、PlayKeys.playVersionで修飾します。

.sbtファイルを使用する場合以外、つまり、Scalaを使用してビルドを記述する場合は、次のことを実行して、スコープ内でPlayKeysを使用できます。

import play.Play.autoImport._
import PlayKeys._

§明示的なscalaVersion

Play 2.3は、Scala 2.11とScala 2.10の両方をサポートしています。Playプラグインは、以前はscalaVersion sbt設定を自動的に設定していました。次に、使用するScalaのバージョンを示す必要があります。

Scalaバージョンを含めるように、build.sbtまたはBuild.scalaを更新します

Scala 2.11の場合

scalaVersion := "2.11.1"

Scala 2.10の場合

scalaVersion := "2.10.4"

§sbt-web

Play 2.3の最大の新しい機能は、sbt-webの導入です。要約すると、sbt-webを使用すると、Html、CSS、およびJavaScriptの機能をPlayのコアから純粋なsbtプラグインのファミリにファクタリングできます。これには、2つの主な利点があります。

• PlayはHtml、CSS、およびJavaScriptに関する意見が少なくなりました。そして
• sbt-webには独自のコミュニティがあり、Playと並行して発展できます。

Triremeを介してJVM内で、またはNode.jsを使用してネイティブにsbt-webプラグインを実行できるという事実を含む、他の利点もあります。sbt-webは開発環境であり、Playアプリケーションの実行には関与しないことに注意してください。Triremeはデフォルトで使用されますが、Node.jsがインストールされていて、ビルドで驚異的なパフォーマンスを望む場合は、sbtのSBT_OPTS環境変数を介してシステムプロパティを提供できます。例：

export SBT_OPTS="$SBT_OPTS -Dsbt.jse.engineType=Node"

sbt-webの機能の1つは、フォルダー名として「javascripts」または「stylesheets」を使用するかどうかを気にしないことです。適切なファイル名拡張子を持つファイルは、app/assetsフォルダー内からフィルター処理されます。

sbt-webのニュアンスは、すべてのアセットがpublicフォルダーから提供されることです。したがって、以前にアセットがpublicフォルダーの外に存在していた場合、つまり、次の例のようにplayAssetsDirectories設定を使用した場合は、

playAssetsDirectories <+= baseDirectory / "foo"

…次に、次を使用する必要があります

unmanagedResourceDirectories in Assets += baseDirectory.value / "foo"

…ただし、ファイルがターゲットのpublicフォルダーに集約されることに注意してください。これは、「public/a.js」にあるファイルが「foo/a.js」にあるファイルで上書きされることを意味します。または、プロジェクトのpublicフォルダーのサブフォルダーを使用して、それらに名前空間を設定します。

以下に、Play 2.3のリリース時のすべてのsbt-web関連コンポーネントとそのバージョンを示します。

§ライブラリ

"com.typesafe" %% "webdriver" % "1.0.0"
"com.typesafe" %% "jse" % "1.0.0"
"com.typesafe" %% "npm" % "1.0.0"

§sbtプラグイン

"com.typesafe.sbt" % "sbt-web" % "1.0.0"
"com.typesafe.sbt" % "sbt-webdriver" % "1.0.0"
"com.typesafe.sbt" % "sbt-js-engine" % "1.0.0"

"com.typesafe.sbt" % "sbt-coffeescript" % "1.0.0"
"com.typesafe.sbt" % "sbt-digest" % "1.0.0"
"com.typesafe.sbt" % "sbt-gzip" % "1.0.0"
"com.typesafe.sbt" % "sbt-less" % "1.0.0"
"com.typesafe.sbt" % "sbt-jshint" % "1.0.0"
"com.typesafe.sbt" % "sbt-mocha" % "1.0.0"
"com.typesafe.sbt" % "sbt-rjs" % "1.0.1"

§WebJars

WebJarsは、Playアプリケーションへのアセットの提供において重要な役割を果たすようになりました。たとえば、ビルドファイルに次の依存関係を追加するだけで、人気のBootstrapライブラリを使用することを宣言できます。

libraryDependencies += "org.webjars" % "bootstrap" % "3.2.0"

WebJarsは、便宜上、publicアセットを基準としたlibフォルダーに自動的に抽出されます。たとえば、RequireJsへの依存関係を宣言した場合、次のような行を使用してビューから参照できます。

<script data-main="@routes.Assets.at("javascripts/main.js")" type="text/javascript" src="@routes.Assets.at("lib/requirejs/require.js")"></script>

lib/requirejs/require.jsパスに注意してください。libフォルダーは抽出されたWebJarアセットを示し、requirejsフォルダーはWebJar artifactIdに対応し、require.jsはWebJarのルートにある必要なアセットを参照します。

§npm

プロジェクトのルートにpackage.jsonファイルを宣言することで、npmとWebJarsの両方を使用できます。npmパッケージのアセットは、WebJarsと同じlibフォルダーに抽出されるため、コードの観点からは、アセットがWebJarから提供されたか、npmパッケージから提供されたかを気にする必要はありません。

ユーザーの視点からは、以前のPlayのリリースと同等の機能を提供することを目指しています。内部的には大きな変更がありましたが、ユーザーにとっての移行はわずかであるはずです。このセクションの残りの部分では、sbt-webに置き換えられたPlayの各部分を見て、変更すべき内容を説明します。

§CoffeeScript

通常はplugins.sbtファイルで、プラグインを宣言する必要があります。

addSbtPlugin("com.typesafe.sbt" % "sbt-coffeescript" % "1.0.0")

Coffeescriptのオプションが変更されました。新しいオプションは以下のとおりです。

• sourceMap 設定すると、sourceMapファイルが生成されます。デフォルトはtrueです。

CoffeeScriptKeys.sourceMap := true

• bare 設定すると、トップレベル関数の安全ラッパーなしでJavaScriptが生成されます。デフォルトはfalseです。

CoffeeScriptKeys.bare := false

詳細については、プラグインのドキュメントを参照してください。

§LESS

通常はplugins.sbtファイルで、プラグインを宣言する必要があります。

addSbtPlugin("com.typesafe.sbt" % "sbt-less" % "1.0.0")

エントリポイントは、フィルターを使用して宣言されるようになりました。たとえば、foo.lessとbar.lessが必要であることを宣言するには、以下のようにします。

includeFilter in (Assets, LessKeys.less) := "foo.less" | "bar.less"

以前に、LESSファイル名の前にアンダースコアが付いたファイルは無視され、他のすべてのLESSファイルがコンパイルされるという動作を使用していた場合は、次のフィルターを使用します。

includeFilter in (Assets, LessKeys.less) := "*.less"

excludeFilter in (Assets, LessKeys.less) := "_*.less"

Play 2.2とは異なり、sbt-lessプラグインを使用すると、ユーザーは元のLESSソースファイルと生成されたソースマップをダウンロードできます。これにより、最新のWebブラウザでのデバッグが容易になります。この機能は、本番モードでも有効になっています。

プラグインのオプションは次のとおりです。

詳細については、プラグインのドキュメントを参照してください。

§Closure Compiler

Closure Compilerは置き換えられました。JavaScriptの検証と最小化という2つの重要な機能は、それぞれJSHintとUglifyJS 2にファクタリングされました。

JSHintを使用するには、通常はplugins.sbtファイルで、それを宣言する必要があります。

addSbtPlugin("com.typesafe.sbt" % "sbt-jshint" % "1.0.0")

オプションは、JSHint Webサイトに従って指定でき、デフォルトのセットも共有します。オプションを設定するには、プロジェクトのベースディレクトリ内に.jshintrcファイルを提供できます。そのようなファイルがない場合は、ホームディレクトリで.jshintrcファイルが検索されます。この動作は、プラグインのJshintKeys.config設定を使用することでオーバーライドできます。
JshintKeys.configは、構成ファイルの場所を指定するために使用されます。

詳細については、プラグインのドキュメントを参照してください。

UglifyJS 2は現在、RequireJSプラグイン（次に説明）を通じて提供されています。将来の目標は、RequireJSが使用されていない状況でも、スタンドアロンのUglifyJS 2プラグインを提供することです。

§RequireJS

RequireJS Optimizer（rjs）は、はるかに使いやすくなるはずの新しいものに完全に置き換えられました。新しいrjsは、sbt-webのアセットパイプライン機能の一部です。ビルドごとに呼び出されていた以前のものとは異なり、新しいものはPlayのstageまたはdistタスクを使用してディストリビューションを生成するときにのみ呼び出されます。

rjsを使用するには、通常はplugins.sbtファイルで、それを宣言する必要があります。

addSbtPlugin("com.typesafe.sbt" % "sbt-rjs" % "1.0.1")

プラグインをアセットパイプラインに追加するには、次のように宣言できます。

pipelineStages := Seq(rjs)

sbt-webのsbt-digestプラグインとsbt-gzipプラグインをパイプラインに含めることをお勧めします。sbt-digestは、Playのアセットコントローラーに、将来のキャッシュのためにアセット名をフィンガープリントする機能を提供します。sbt-gzipは、リクエストされたときにアセットコントローラーが優先するアセットのgzipを生成します。この構成のplugins.sbtファイルは次のようになります。

addSbtPlugin("com.typesafe.sbt" % "sbt-digest" % "1.0.0")

addSbtPlugin("com.typesafe.sbt" % "sbt-gzip" % "1.0.0")

そして、パイプライン構成は次のようになります。

pipelineStages := Seq(rjs, digest, gzip)

ステージの順序は重要です。最初にファイルを最適化し、それらのダイジェストを生成し、次にすべての結果のアセットのgzipバージョンを生成する必要があります。

RequireJs最適化のオプションは完全に変更されました。プラグインのオプションは次のとおりです。

詳細については、プラグインのドキュメントを参照してください。

§デフォルトのivyローカルリポジトリとキャッシュ

PlayがランチャーとしてActivatorを使用するようになったため、デフォルトのivyキャッシュとローカルリポジトリを使用するようになりました。つまり、以前にPlayのivyキャッシュに公開して依存していたものはすべて、ホームディレクトリの.ivy2フォルダーにあるローカルivyリポジトリに公開する必要があります。

§結果の再構築

Play 2.2では、いくつかの結果型が非推奨になり、新しい結果構造への移行を容易にするために、いくつかの新しい型が導入されました。Play 2.3では、この再構築が完了します。

§Scalaの結果

Play 2.1の以下の非推奨の型とヘルパーが削除されました。

• play.api.mvc.PlainResult
• play.api.mvc.ChunkedResult
• play.api.mvc.AsyncResult
• play.api.mvc.Async

これらを使用しているコードがある場合は、Play 2.2移行ガイドを参照して、新しい結果構造への移行方法を学んでください。

2.2で計画されていたように、2.3ではplay.api.mvc.SimpleResultの名前がplay.api.mvc.Resultに変更されました（既存のResultトレイトを置き換えます）。移行を容易にするためにタイプエイリアスが導入されました。そのため、Play 2.2のコードはPlay 2.3とソース互換性があるはずですが、最終的にはこのタイプエイリアスを削除するため、非推奨にし、Resultに切り替えることをお勧めします。

§Javaの結果

Play 2.1の以下の非推奨の型とヘルパーが削除されました。

• play.mvc.Results.async
• play.mvc.Results.AsyncResult

これらを使用しているコードがある場合は、Play 2.2移行ガイドを参照して、新しい結果構造への移行方法を学んでください。

2.2で計画されていたように、2.3ではplay.mvc.SimpleResultの名前がplay.mvc.Resultに変更されました。これは、ほとんどのJavaコードには透過的であるはずです。これが最も影響を与えるのは、Global.javaのエラーコールバックと、カスタムアクションです。

§テンプレート

テンプレートエンジンは、別のプロジェクトであるTwirlになりました。

§コンテンツタイプ

テンプレートのコンテンツタイプは、twirlパッケージに移動しました。play.mvc.Content型が参照されている場合は、play.twirl.api.Contentに更新する必要があります。たとえば、Play Javaプロジェクトの次のコード

import play.mvc.Content;

Content html = views.html.index.render("42");

はエラーを生成します。

[error] ...: incompatible types
[error] found   : play.twirl.api.Html
[error] required: play.mvc.Content

代わりにplay.twirl.api.Contentをインポートする必要があります。

§sbtの設定

テンプレートのsbt設定は、sbt-twirlプラグインによって提供されるようになりました。

以前は、テンプレートに追加のインポートを追加すると

templatesImport += "com.abc.backend._"

になり、現在は次のようになります。

TwirlKeys.templateImports += "org.abc.backend._"

以前は、カスタムテンプレート形式の指定は

templatesTypes += ("html" -> "my.HtmlFormat.instance")

になり、現在は次のようになります。

TwirlKeys.templateFormats += ("html" -> "my.HtmlFormat.instance")

完全なscala構文を使用するsbtビルドの場合、TwirlKeysは次のようにインポートできます。

import play.twirl.sbt.Import._

§Html.emptyがHtmlFormat.emptyに置き換えられました

以前にHtml.empty (play.api.templates.Html.empty) を使用していた場合は、play.twirl.api.HtmlFormat.empty を使用する必要があります。

§Play WS

WSクライアントはオプションのライブラリになりました。プロジェクトでWSを使用している場合は、ライブラリの依存関係を追加する必要があります。Javaプロジェクトの場合は、新しいパッケージに更新する必要もあります。

§Javaプロジェクト

build.sbtにライブラリの依存関係を追加します。

libraryDependencies += javaWs

ソースファイル内の新しいライブラリパッケージに更新します。

import play.libs.ws.*;

§Scalaプロジェクト

build.sbtにライブラリの依存関係を追加します。

libraryDependencies += ws

さらに、WSクライアントの使用には、スコープ内のPlayアプリケーションが必要です。通常、これは次を追加することで実現されます。

import play.api.Play.current

WS APIがわずかに変更され、WS.clientは、基盤となるAsyncHttpClientオブジェクトではなく、WSClientのインスタンスを返すようになりました。WS.client.underlyingを呼び出すことで、AsyncHttpClientにアクセスできます。

§Anorm

この新しいリリースでは、Anormにいくつかの変更が含まれています。

型安全性を向上させるため、クエリパラメータの型は可視である必要があり、適切に変換できるようにする必要があります。Anyをパラメータ値として明示的に、または型消去によって使用すると、コンパイルエラーNo implicit view available from Any => anorm.ParameterValueが発生するようになりました。

// Wrong
val p: Any = "strAsAny"
SQL("SELECT * FROM test WHERE id={id}").
  on('id -> p) // Erroneous - No conversion Any => ParameterValue

// Right
val p = "strAsString"
SQL("SELECT * FROM test WHERE id={id}").on('id -> p)

// Wrong
val ps = Seq("a", "b", 3) // inferred as Seq[Any]
SQL("SELECT * FROM test WHERE (a={a} AND b={b}) OR c={c}").
  on('a -> ps(0), // ps(0) - No conversion Any => ParameterValue
    'b -> ps(1), 
    'c -> ps(2))

// Right
val ps = Seq[anorm.ParameterValue]("a", "b", 3) // Seq[ParameterValue]
SQL("SELECT * FROM test WHERE (a={a} AND b={b}) OR c={c}").
  on('a -> ps(0), 'b -> ps(1), 'c -> ps(2))

安全な変換なしで値を渡す必要がある場合は、anorm.Object(anyVal)を使用して不透明なパラメータを設定できます。

さらに、パラメータ値に関する型消去の問題が修正されました。型はParameterValue[_]ではなく、単にParameterValueになりました。

パラメータ名（.on(...)を使用する場合）の型も統一されました。現在、StringとSymbolのみが名前としてサポートされています。

型Pk[A]は非推奨になりました。カラムマッピングとしては引き続き使用できますが、（型安全性の改善の結果として）クエリパラメータとしてId[A]またはNotAssignedを明示的に渡す必要があります。

// Column mapping, deprecated but Ok
val pk: Pk[Long] = SQL("SELECT id FROM test WHERE name={n}").
  on('n -> "mine").as(get[Pk[Long]].single)

// Wrong parameter
val pkParam: Pk[Long] = Id(1l)
val name1 = "Name #1"
SQL"INSERT INTO test(id, name) VALUES($pkParam, $name1)".execute()
// ... pkParam is passed as Pk in query parameter, 
// which is now wrong as a parameter type (won't compile)

// Right parameter Id
val idParam: Id[Long] = Id(2l) // same as pkParam but keep explicit Id type
val name2 = "Name #2"
SQL"INSERT INTO test(id, name) VALUES($idParam, $name2)".execute()

// Right parameter NotAssigned
val name2 = "Name #3"
SQL"INSERT INTO test(id, name) VALUES($NotAssigned, $name2)".execute()

非推奨のPk[A]は、AnormでカラムマッピングとクエリパラメータとしてサポートされているOption[A]に似ているため、Id[A]をSome[A]で、NotAssignedをNoneで置き換えることが推奨されます。

// Column mapping, deprecated but Ok
val pk: Option[Long] = SQL("SELECT id FROM test WHERE name={n}").
  on('n -> "mine").as(get[Option[Long]].single)

// Assigned primary key as parameter
val idParam: Option[Long] = Some(2l)
val name1 = "Id"
SQL"INSERT INTO test(id, name) VALUES($idParam, $name1)".execute()

// Right parameter NotAssigned
val name2 = "NotAssigned"
SQL"INSERT INTO test(id, name) VALUES($None, $name2)".execute()

§Bootstrap

組み込みのBootstrapフィールドコンストラクタは非推奨となり、Playの将来のバージョンで削除されます。

これにはいくつかの理由があります。1つは、Bootstrapがバージョン間で大幅に、かつ頻繁に変更されるため、Playが提供する組み込みのサポートはすぐに古くなり、現在のBootstrapバージョンと互換性がなくなることがわかったためです。

もう1つの理由は、現在のBootstrapのCSSクラスの要件は、Playのフィールドコンストラクタだけでは実装できず、カスタム入力テンプレートも必要になるためです。

今後の方針としては、これがコミュニティにとって価値のある機能である場合、特定のBootstrapバージョンに特化したBootstrapフォームヘルパーテンプレートの別セットを提供するサードパーティモジュールを作成でき、現在提供できるよりもはるかに優れたユーザーエクスペリエンスが可能になると考えています。

§セッションタイムアウト

セッションタイムアウトの設定項目であるsession.maxAgeは、以前は秒単位で定義された整数でした。現在は期間になり、1hや30mのような値で指定できます。残念ながら、時間単位が指定されていない場合のデフォルト単位はミリ秒であるため、以前は3600の設定値は1時間として扱われていましたが、現在は3.6秒として扱われます。時間単位を追加するように設定を更新する必要があります。

§Java JUnitスーパークラス

JavaのWithApplication、WithServer、WithBrowser JUnitテストスーパークラスは、@Beforeアノテーション付きメソッドを定義するように変更されました。これは、以前はアプリケーションを明示的に開始する必要があった場合、

@Before
public void setUp() {
    start();
}

今は必要ありません。カスタムアプリケーションを提供する必要がある場合は、provideFakeApplicationメソッドをオーバーライドすることで実行できます。

@Override
protected Application provideFakeApplication() {
    return Helpers.fakeApplication(Helpers.inMemoryDatabase());
}

§セッションとフラッシュの暗黙的パラメータ

Scalaコントローラは、暗黙的なRequestHeaderを受け取る暗黙的なSession、Flash、Langパラメータを提供します。これらは利便性のために存在し、たとえばテンプレートが暗黙的な引数を受け取ると、コントローラで自動的に提供されます。これらの名前は、同じ名前のアプリケーションローカル変数によってこれらのパラメータ名が隠蔽される可能性のある競合を避けるために変更されました。sessionはrequest2Sessionに、flashはflash2Sessionに、langはlang2Sessionになりました。したがって、これらを明示的に呼び出したコードはすべて壊れます。

これらの暗黙的なメソッドを明示的に呼び出すことは推奨されません。session、flash、langパラメータはすべてRequestHeaderで利用可能であり、RequestHeaderプロパティを使用すると、コードを読んでいるときにそれらがどこから来たのかがより明確になります。古いメソッドを使用しているコードがある場合は、RequestHeaderの対応するプロパティに直接アクセスするように変更することをお勧めします。

次へ: Play 2.2

このドキュメントにエラーを見つけましたか？ このページのソースコードはこちらにあります。 ドキュメントガイドラインを読んだ後、プルリクエストを自由に投稿してください。 質問や共有するアドバイスはありますか？ コミュニティフォーラムにアクセスして、コミュニティとの会話を始めましょう。