RailsアプリをテストするためのDockerコンテナを設定する
Ruby / Rails開発者として、私たちはテストを書くのが大好きです。テストはソフトウェア開発の不可欠な部分です。優れたテストは、高品質のコードを書くのに役立ちます。これらは開発プロセス全体に付加価値をもたらしますが、テストを適切に管理しないと、速度が低下する可能性があります。不適切に管理されているテストの症状の一部を次に示します。
- テストの実行には長い時間がかかります。
- テストは信頼性が低く、ランダムに失敗します。
- テストはマシンによって動作が異なります。
- すべてのテストスイートを実行すると、CIの速度が低下します。
このブログ投稿では、コンテナを使用してテストの信頼性を高める方法について説明します。これは、高品質のソフトウェアを提供するのに役立ちます。
コンテナーのトピックに飛び込む前に、まず、ユニットテストと統合テストの違いについて理解し、同じページにいるようにしましょう。
単体テストは、コードのブロックを分離してテストする方法です。これらは、コードブロックの機能をテストするのに役立ちますが、依存関係をテストするのには役立ちません。たとえば、簡単な方法は次のとおりです。
def sum(a, b)
a + b
end
これは2つの数値を合計する関数であり、非常に単純です。この関数のテストは非常に簡単です。しかし、この関数が外部サービスに依存している場合はどうでしょうか。このメソッドは、合計が完了するとデータベースに書き込む必要があります。
def sum!(a, b)
c = a + b
Sum.create(value: c)
end
このコードブロックでは、値が追加され、データベースに保存されます。このコードブロックをテストするには、データベースサーバーを実行する必要があります。データベースサーバーを実行してこれをテストすると、単体テストではなくなります。これには外部依存関係が必要です。また、データベース接続と、レコードがデータベースに保存されているかどうかもテストします。この場合、このテストは統合テストです。
単体テストは単独の単体テストにすることができます (すべての依存関係をモック/スタブする)または社交的な単体テスト (他の依存関係との通信を許可します)。人々はユニットテストのさまざまな定義を提案しています。このブログのコンテキストでは、私たちが話している単体テストのタイプは、単独の単体テストです。
モックを使用して外部の依存関係を削除すると、テストの実行が速くなります。単体テストを使用している間、これらの依存関係は省略しますが、アプリケーションが期待どおりに機能することを確認するには、依存関係をテストすることも同様に重要です。データベース、ネットワーク呼び出し、ファイルなど、これらの外部依存関係をテストするために作成するテストは、統合テストです。 。
単体テストと同様に、人々は統合テストのさまざまな定義を提案しています。ただし、基本的な考え方は同じです。違いはスコープだけです。データベースに書き込む小さな関数は、統合テストになる可能性があります。システムの複数の部分を接続するより広範な機能も統合テストです。ここで話しているテストは、より狭い部分に焦点を当てています。テストが狭いほど、より多くのテストを作成する必要があります。ただし、より広範なテストでは、必要なテストの数は減少します。
統合テストの実行中は、アプリケーションと、データベースや外部サービスなどの依存関係を実行する必要があります。これらの依存関係の管理は難しい場合があります。
Dockerの基礎
Dockerは、アプリケーションをその環境(オペレーティングシステム)から抽象化し、ホストとは別に実行するのに役立つテクノロジーです。これは仮想マシンに似ていますが、より高速で効率的です。 Dockerを使用すると、アプリケーションコードとその依存関係を単一のコンテナーにパッケージ化できます。これにより、コードが移植可能になり、開発、テスト、本番環境で同じDockerイメージを実行できるようになります。これにより、アプリケーションが実行される環境の一貫性が保証されます。ホストサーバーに依存しないため、すべての環境でアプリケーションの動作を予測可能にします。 Dockerは、開発者がアプリケーションとその環境を実行および管理するのに役立ちます。これには、簡単なコマンドを使用したビルド、実行、デプロイ、更新が含まれます。
いくつかの重要な用語を理解しましょう:
-
Dockerfile -Dockerfileは、アプリケーションに必要な依存関係を定義する単なるファイルです。必要なオペレーティングシステム、データベースクライアントライブラリ、またはアプリケーションに必要なパッケージを指定できます。ここでは、アプリケーションの実行に必要なコマンドも定義します。 Dockerfileはベースイメージから始まります。これらのベースイメージは、オペレーティングシステムまたはプログラミング言語である可能性があります。
-
画像 -画像は、コンテナの実行に必要な手順を示す青写真です。画像はさまざまなレイヤーで作成されます。 Dockerfileで定義されたすべてのステップは、イメージ内のレイヤーです。これにより、再利用性が向上し、中間レイヤーをキャッシュしてイメージをより高速に構築するのに役立ちます。
-
コンテナ -コンテナは実際の画像です。これらも停止状態になる可能性があります。コンテナーは、Dockerイメージから開始できます。 1つのDockerイメージで複数のDockerコンテナーを開始できます。コンテナは、イメージで指定された情報を保持します。アプリケーションの実行中に画像に加えられたすべての変更が保存される薄いコンテナレイヤーがあります。
-
Dockerの作成 --Docker Composeは、複数のコンテナーの管理に役立つ別のツールです。同じDockerイメージから複数のコンテナーを持つことができます。また、異なるDockerイメージからの複数のコンテナーが必要になる場合があり、これらのコンテナーは相互に作用する必要があります。 DockerComposeはコンテナーを管理します。利用できるツールは他にもありますが、このコンテキストでは、その単純さのためにDockerComposeのみを使用します。
仮想マシンはホストハイパーバイザーの上にあり、別のオペレーティングシステムをインストールする必要があるため、より多くのホストリソースが使用されます。ただし、Dockerを使用する場合は、ホストオペレーティングシステムにDockerエンジンをインストールするだけで済み、ホストリソースの管理はDockerによって行われます。 Dockerは、開発者とシスオペの両方の生活を楽にするのに役立つため、DevOpsカルチャーで非常に人気があります。
Dockerは、最小限のリソース消費で、実行中のアプリケーションまたはテストをホスト環境から分離します。テストにdockerを使用する利点のいくつかを次に示します。
-
軽量: Dockerコンテナは軽量です。これは、1つのテストプロセスが別のテストプロセスで問題を引き起こすことなく、複数のコンテナを同時に実行するのに役立ちます。
-
ポータブル: Dockerイメージは移植可能であり、どの環境でも実行できます。同じイメージを再利用してローカル環境とCI環境でテストを実行できるため、これはCIで役立ちます。
-
バージョン管理: 複数のアプリケーションを使用したり、依存関係をアップグレードしたりするには、ローカルマシンに異なるバージョンの依存関係が必要です。これは、Dockerなしで管理するのは非常に困難です。 Dockerを使用すると、さまざまなバージョンでさまざまなコンテナーを実行できます。さまざまなバージョンでテストを実行して、確認することもできます。
-
マイクロサービスの簡単な管理 :マイクロサービスでは、テストも分散されて複雑になります。これは、依存するマイクロサービスを管理する必要があることを意味します。 DockerとDockerComposeは、これらのサービスの依存関係を管理するのに役立ちます。
これを試すには、次のように設定されていることを確認しましょう。
- Docker
- Docker-作成
- Ruby 2.7(オプション、RubyをDockerコンテナーに追加しますが、テストには役立ちます)
- レール(5.1以降を推奨)
簡単なRailsアプリを作成し、それをコンテナー化することから始めましょう。私は新しいRailsアプリから始めています。既存のRailsアプリをコンテナ化することもできます。
rails new calculator
Dockerfile
という名前のファイルを作成します 次の内容で:
FROM ruby:2.7
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y nodejs yarn
RUN mkdir /calculator
WORKDIR /calculator
COPY Gemfile /calculator/Gemfile
COPY Gemfile.lock /calculator/Gemfile.lock
RUN bundle install
COPY package.json /calculator/package.json
COPY yarn.lock /calculator/yarn.lock
RUN yarn install --check-files
COPY . /calculator
EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0"]
定義したDockerfileにはRuby2.7ベースイメージがあります。 NodeJSとYarnが必要なので、次のステップはそれらをインストールすることです。インストールしたら、bundle install
を実行します およびyarn install
。最後に、すべてのコードをコピーして、3000ポートをエクスポートしてRailsサーバーを実行します。これは非常に単純なDockerfileです。これにより、Railsアプリがドッキングされます。
これで、Dockerイメージを作成して実行し、実行されていることを確認できます。
Dockerイメージを作成します:
docker build . -t calculator
コンテナを実行します:
docker run -p 3000:3000 calculator
計算ロジックを追加できる計算と呼ばれるモデルを作成しましょう。このモデルを使用して、いくつかのロジックとテストを記述します。 DockerComposeを使用してこれらのテストの依存関係を管理する方法を調べることができます。
現在、SQLiteでRailsを実行しています。 SQLiteではなくPostgresに変更しましょう。これは、次のコマンドで簡単に実行できます。
rails db:system:change --to=postgresql
計算モデルを生成します:
bundle exec rails generate model calculation
計算スキーマにいくつかのフィールドを追加します:
# db/migrate/create_calculation.rb
class CreateCalculations < ActiveRecord::Migration[6.0]
def change
create_table :calculations do |t|
t.integer :x
t.integer :y
t.integer :result
t.timestamps
end
end
end
次に、コンテナ内での移行をデータベースで実行してみましょう。
docker-compose exec web rails db:migrate
データベースはコンテナ内で実行されていないため、このコマンドを実行するとエラーがスローされます。
rake aborted!
PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
Postgresイメージを別のイメージとして実行し、それらの間にネットワークを追加できます。このコンテナ通信を管理するために、DockerComposeを使用できます。
DockerComposeを使用した複数のコンテナーの管理
Railsアプリをコンテナ化すると、DockerComposeを使用してサービスに依存関係を追加できます。アプリケーションへの依存関係はPostgresです。
Postgres Dockerイメージは公開されているため、作成する必要はありません。ただし、データベースコンテナとRailsアプリコンテナを管理する必要があります。
version: "3.0"
services:
db:
image: postgres
environment:
POSTGRES_USER: calculator
POSTGRES_PASSWORD: password
POSTGRES_DB: calculator_test
web:
build: .
ports:
- "3000:3000"
depends_on:
- db
environment:
CALCULATOR_DATABASE_PASSWORD: password
次に、database.yaml
に移動します ファイルを作成し、データベースを別のホストに変更します。ホストは、DockerComposeファイルのサービス内で指定された名前になります。この場合、ホストはdb
です。 。 postgres
でDBパスワードが同じであることを確認してください サービスとweb
サービス。また、Docker Composeファイルで指定されているように、ユーザー名、パスワード、データベース名を変更します。
# database.yaml
development:
<<: *default
database: calculator_development
username: calculator
password: <%= ENV['CALCULATOR_DATABASE_PASSWORD'] %>
これで、次の1つのコマンドを使用してコンテナを起動できます。
docker-compose up
これにより、データベースとRailsサーバーの両方が起動します。これで移行コマンドを実行でき、Postgresに接続して移行を実行できるはずです。
すべてのセットアップの準備ができたので、モデル内に簡単なメソッドを記述して、メソッドをテストしましょう。
# calculation.rb
class Calculation < ApplicationRecord
def self.sum(x, y)
result = x + y
Calculation.create(x: x, y: y, result: result)
result
end
end
このsumメソッドは、数値を加算するだけでなく、データベースに数値を保存します。したがって、このメソッドをテストするには、データベースインスタンスが実行されている必要があります。
データベースに接続する必要があるため、このテストは統合テストになります。
ミニテストを使用してテストを作成します。これはRailsのデフォルトです。
# calculation_test.rb
require 'test_helper'
class CalculationTest < ActiveSupport::TestCase
test "should sum and save the data" do
result = Calculation.sum(1, 2)
c = Calculation.last
assert result, 3
assert c.result, result
end
end
テストを実行します:
docker-compose exec web rails test
上記のテストでは、sumメソッドが値を加算してデータベースに値を保存しているかどうかをテストしています。 Docker Composeを使用すると、データベースに接続する非常に簡単な方法があります。
ここでは、メソッドはデータベースに依存しています。依存関係は、データベースだけでなく、RESTAPIを提供するサードパーティのサービスでもかまいません。それでは、sum
を提供するサードパーティのサービスを使用してみましょう。 メソッド。独自に作成する代わりに使用できます。
# calculation.rb
class Calculation < ApplicationRecord
def self.sum(x, y)
# The hostname should be the same as it is specified in the docker-compose file
url = 'https://sumservice:4010/sum'
uri = URI(url)
params = { :x => x, :y => y }
uri.query = URI.encode_www_form(params)
res = Net::HTTP.get_response(uri)
throw "Error" unless res.is_a?(Net::HTTPSuccess)
result = res.body.to_i
Calculation.create(x: x, y: y, result: result)
result
end
end
依存関係としてデータベースに対して行ったのと同様のことをRESTAPIに対して行うことができます。これらが有効なエンドポイントであることを確認する必要がありますが、テスト中に実際のサービスに電話をかけたくありません。この場合、モック/スタブテストを作成できますが、そうすると、これらのテストは統合テストにはなりません。テストが可能な限り現実的であることを確認したいと思います。この目的のために、コンテナで実行するモックAPIエンドポイントを作成し、モックコンテナAPIサービスを呼び出して、結果を返すことができます。
最初にテストを変更しましょう:
# calculation_test.rb
require 'test_helper'
class CalculationTest < ActiveSupport::TestCase
test "should sum and save the data" do
result = Calculation.sum(1, 2)
c = Calculation.last
# we don't need this assetion as we are deligation this responsibility to external service:
# assert result, 3 // Not needed
assert c.result, result
end
end
ここでは、sumAPIによって提供された結果がデータベースに適切に保存されているかどうかのみをテストするようにテストケースを変更しました。合計の実際の値が正しいかどうかをテストする必要はありません。これは外部サービスによって処理されるため、信頼できます。
モックサーバーを生成するには、openAPIを使用します。簡単なSwagger定義を作成しましょう:
ルートディレクトリに新しいフォルダを作成し、mock
という名前を付けます 。フォルダ内に、ファイル名api.yaml
を作成します
# api.yaml
swagger: "2.0"
info:
description: "This is a sum api provider"
version: "1.0.0"
title: "API Provider"
host: "https://mock-service.com/"
basePath: "/api"
schemes:
- "https"
- "http"
paths:
/sum:
get:
produces:
- "application/json"
parameters:
- name: "x"
in: "query"
description: "x value"
required: true
type: "integer"
- name: "y"
in: "query"
description: "y value"
required: true
type: "integer"
responses:
"200":
description: "successful operation"
schema:
type: "integer"
example: 3
仕様に基づいてこのサーバーを実行するには、任意のモックサービスプロバイダーを使用できます。プリズムというツールを使用します。 docker-composeファイルに追加できるdockerイメージが利用可能です:
version: "3.0"
services:
db:
image: postgres
environment:
POSTGRES_USER: calculator
POSTGRES_PASSWORD: password
POSTGRES_DB: calculator_test
web:
build: .
ports:
- "3000:3000"
depends_on:
- db
- sumservice
environment:
CALCULATOR_DATABASE_PASSWORD: password
sumservice:
image: stoplight/prism:4
command: mock -h 0.0.0.0 "/tmp/api.yaml"
volumes:
- ./mock:/tmp/
ports:
- 4010:4010
init: true
それでは、テストを実行して、期待どおりに機能するかどうかを確認しましょう。
> docker-compose exec web rails test
Finished in 0.337710s, 2.9611 runs/s, 5.9222 assertions/s.
1 runs, 2 assertions, 0 failures, 0 errors, 0 skips
うん!これでテストが実行されました。このメソッドは、sumサービスのDockerイメージに接続して合計を取得し、Postgresに接続してデータを保存します。すべての依存関係はDockerComposeによって管理されるため、以前にインストールされた依存関係について心配する必要はありません。このテストを任意のマシンに移動すると、依存関係のインストールは必要ありません。マシンに必要なのはDockerだけです。
アプリケーションがRedisやMemcachedなどの他の依存関係に依存している場合、これらはdockerhubにあります。必要に応じて、これらのイメージをDockerComposeファイルに追加できます。
Rails 5.1.5+は、テストの並行実行をサポートしています。デフォルトでは、テストはプロセッサーの数に基づいてRails6から並行して実行されます。テストの実行中に、並列テストの数に基づいてデータベースインスタンスを作成します。 4つのプロセッサがある場合は、データベース「calculator_test-0」、calculator_test-1、calculator_test-2、およびcalculator_test-3が作成されます。 postgres cliに移動してデータベースを確認すると、次のように表示されます。
> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-------------------+------------+----------+------------+------------+---------------------------
calculator_test | calculator | UTF8 | en_US.utf8 | en_US.utf8 |
calculator_test-0 | calculator | UTF8 | en_US.utf8 | en_US.utf8 |
calculator_test-1 | calculator | UTF8 | en_US.utf8 | en_US.utf8 |
calculator_test-2 | calculator | UTF8 | en_US.utf8 | en_US.utf8 |
calculator_test-3 | calculator | UTF8 | en_US.utf8 | en_US.utf8 |
これで、Railsやミニテストを使用していない場合や古いバージョンのRailsを使用している場合でも、Dockerを使用してテストを作成すると、テストを並行して実行できます。 Railsは並列テスト用のデータベースを自動的に作成しますが、Redisやmemcachedなどの他の依存関係がある場合は、手動で管理する必要がある場合があります。
すべての依存関係が管理されているため、さまざまな引数を指定してDocker Composeを実行し、テストを並行して実行できます。この目的のために、テストを並行して実行するフォルダーを指定し、複数のDocker Composeファイルの作成を実行して、それらを並行して実行できます。
DockerおよびDockerComposeコマンドを使用してテストを実行しているため、コマンドは長くなります。日々の開発を行っている間、それらを覚えて実行するのは難しい場合があります。単純なコマンドに単純化するために、addMakefileを使用してみましょう。 Makefileは、ターゲットコマンドの実行を参照するために使用される単純なテキストファイルです。
.PHONY: test
up:
docker-compose up
down:
docker-compose down
test:
docker-compose exec web rails test
makefileにいくつかのコマンドを追加しました。これは、アプリケーションの必要に応じて拡張できます。 Railsアプリケーションのルートディレクトリにmakefileを追加します。このmakefileを取得したら、次のコマンドを使用してテストを実行できます。
コンテナを起動します:
> make up
テストを実行します:
> make test
アプリケーションの開発中にDockerを使用することもできます。これは、アプリケーションがテスト、開発、および本番環境で一貫して動作することを保証するのに役立ちます。上記のコンテナをローカル開発に使用するために変更する必要があるものを確認しましょう。
アプリケーションをローカルで実行しているときに、コードに変更を加えたときに、アプリケーションにローカルサーバーの変更を反映させたいと考えています。現在のシナリオでは、コードがマシンからDockerにコピーされ、サーバーが起動します。そのため、ローカルマシンのファイルに変更を加えても、Dockerには反映されません。コードが常に同期していることを確認するために、ボリュームマウントを使用できます。
Docker Composeファイルで、ボリュームを追加しましょう:
version: "3.0"
services:
db:
image: postgres
environment:
POSTGRES_USER: calculator
POSTGRES_PASSWORD: password
POSTGRES_DB: calculator_test
web:
build: .
volumes:
- .:/calculator # Volume mounted
ports:
- "3000:3000"
depends_on:
- db
- sumservice
environment:
CALCULATOR_DATABASE_PASSWORD: password
sumservice:
image: stoplight/prism:4
command: mock -h 0.0.0.0 "/tmp/api.yaml"
volumes:
- ./mock:/tmp/
ports:
- 4010:4010
init: true
これで、サーバーに何か変更を加えると、その変更が反映されます。コントローラを作成し、sumメソッドを呼び出してこれを試してみましょう:
# controllers/calculation_controller.rb
class CalculationController < ApplicationController
def index
result = Calculation.sum(params[:x], params[:y])
render json: {result: result}
end
end
ルートルートを追加します:
# routes.rb
Rails.application.routes.draw do
# For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
root "calculation#index"
end
ここで、戻ってブラウザでアプリを確認すると、期待される応答が得られます。
模擬のsumservice
を使用してサーバーを起動していることに注意してください。 したがって、URLでクエリパラメータとして提供するものに関係なく、常に2が返されます。これは開発を行うための良い方法ではないようですが、モックサービスプロバイダーを使用することには利点があります。マイクロサービスを開発する場合、依存するサービスが多数存在する可能性があり、サービスを開始する前に起動する必要があります。これにより、開発中の生産性が向上します。私たちは他のサービスには関心がなく、私たちが開発しているサービスのみに関心があります。
実際のサービスでどのように機能するかを最終的に検証する場合は、新しいDocker Composeファイルを作成し、それをサービスの実際のイメージに置き換えることで確認できます。内部サービスの場合は、最新の安定したDockerイメージに置き換えるだけです。開発環境でも模擬サービスを利用することをお勧めします。
.dockerignore
アプリケーションが大きくなると、依存関係によってDockerビルドコンテキストが大きくなります。ビルドコンテキストが大きいほど、Dockerイメージのビルドに時間がかかります。ボリュームマウントでさえ、アプリケーションのサイズが大きくなると遅延が発生する可能性があります。この場合、不要なファイルを.dockerignore
に追加できます。 ビルドコンテキストを減らすためのファイル。
.git*
log/*
README.md
node_modules
Railsサーバーがコンテナーで実行されているときに、コンテナーの終了時にPIDファイルが削除されなかったため、サーバーが既に実行されていることを示すエラーメッセージが表示されることがあります。このエラーを削除するには、ENTRYPOINTを追加して、server.pid
を削除します。 ファイル。
FROM ruby:2.7
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y nodejs yarn
RUN mkdir /calculator
WORKDIR /calculator
COPY Gemfile /calculator/Gemfile
COPY Gemfile.lock /calculator/Gemfile.lock
RUN bundle install
COPY package.json /calculator/package.json
COPY yarn.lock /calculator/yarn.lock
RUN yarn install --check-files
COPY . /calculator
EXPOSE 3000
ENTRYPOINT ./entrypoint.sh
CMD ["rails", "server", "-b", "0.0.0.0"]
entrypoint.sh
を作成します ファイル:
#!/bin/bash
set -e
# Remove a potentially pre-existing server.pid for Rails.
rm -f /calculator/tmp/pids/server.pid
# Exec the container's main process (CMD command in rails file)
exec "$@"
実行可能にする
chmod +x entrypoint.sh
これで、Dockerイメージを実行するときに、この問題は発生しません。
統合テストと単体テストを区別することは非常に重要です。単体テストを作成しているときに、データベースなどの外部依存関係をモックすることができます。これは、コードを分離してテストするのに役立ちます。コアビジネスロジックとその依存関係の間で統合テストを実行することも同様に重要です。データベースや外部サービスなどの依存関係は、DockerとDockerComposeを使用して統合してテストできます。これら2つを分離することをお勧めします。それらを別々に実行できるはずです。単体テストを増やし、統合テストを減らすことで、テストをより速く、より確実に実行できます。
このワークフローのいくつかの利点は次のとおりです。
- ユニットテストと統合テストの分離。
- すべてのCIサービスはコンテナーで実行されるため、ローカルとCIで実行されるテストの動作は同じになります。これにより、ローカルマシンとCIサーバーでのテスト動作の一貫性を確保できます。
- コンテナを使用してアプリケーションをデプロイすることも、本番サーバーの一貫性を確保するのに役立ちます。
- 依存関係が適切に管理されているため、信頼性の高いテスト。
- ポータブルテスト。複数の開発者が使用する場合、セットアップにほとんど労力は必要ありません。
-
iOS 13 ダーク モード用にアプリを設定する方法
Apple は、待望の iOS 13 アップデートを 9 月 19 日に、過去 4 年間 (iPhone 6s に遡る) 内に発売されたすべての iPhone でグローバルにリリースしました。 このアップデートの最大の機能の 1 つは、システム全体の iOS 13 ダーク モードでした。スマートフォンのディスプレイから放出される白色光によって引き起こされる眼精疲労に役立つことが期待されています. この機能は、Apple デバイスを使用する最終消費者にとっては喜ばしいことですが、iOS 開発者にとっては、iOS 13 ダーク モードに対応したアプリを準備する作業です。 iOS 13 ダーク
-
Windows 10 でスマホ同期を設定して使用する方法
Android および iOS のスマホ同期アプリと組み合わせて使用される Windows 10 のスマホ同期アプリは、Windows 10 PC でスマートフォンからの写真とテキスト メッセージを同期する唯一の方法です。 Windows 10 のスマホ同期アプリを使用すると、Windows 10 PC を離れることなく、テキスト メッセージを読んで応答したり、電話で写真を表示したりできます。スマホ同期アプリは、Windows 10 October 2018 Update 以降に既にインストールされているため、追加でダウンロードする必要はありません。 まず、スマートフォンを Window