Laravel 8.0以前のバージョンでは、マイグレーションを実行した際にマイグレーションが何もない場合、終了コード1が返されていました。これは、何らかのエラーが発生したと誤解されることがあったため、開発者にとって不便でした。
Laravel 8.0以降では、この挙動が改善され、マイグレーションがない場合には正常に終了し、終了コード0を返すようになりました。これにより、スクリプトやCI/CDパイプラインでの処理がより直感的になりました。
php artisan migrate --force
echo $?
umask=22がパーミッション755になる理由は、実は「計算式」が存在します。この計算により、umaskの値からファイルやディレクトリのパーミッションが導かれます。
まず、umaskはファイルやディレクトリの「パーミッションをマスク（除外）」する役割を持ち、デフォルトのパーミッションからumaskのビットで指定された部分を取り除いたものが最終的なパーミッションになります。
666です（読み書き可能）。777です（読み書き実行可能）。umaskの値は、「削除する」パーミッションを表しており、666または777からumaskの値を引いた結果が、最終的なパーミッションになります。
777です。22を引きます。計算式は次のようになります： 777 - 022 = 7557 - 0 = 7（所有者のパーミッションはrwx）7 - 2 = 5（グループのパーミッションはr-x）7 - 2 = 5（その他のパーミッションはr-x）755（rwxr-xr-x）になります。666です。22を引きます。計算式は次のようになります： 666 - 022 = 6446 - 0 = 6（所有者のパーミッションはrw-）6 - 2 = 4（グループのパーミッションはr--）6 - 2 = 4（その他のパーミッションはr--）644（rw-r--r--）になります。umaskの計算は、「デフォルトパーミッション」から「umaskで指定したビット」を引くことで決定されます。umaskの各桁が0でなければ、それに応じたパーミッションがマスクされ、最終的なパーミッションが決まります。
具体的には、アプリケーションのレビューを開始する前に、いくつかの点を確認する必要があるという内容です。以下に、メールのポイントを日本語で解説します。
このメールに返信し、アプリが上記の条件に該当しないことを確認する必要があります。確認が終わると、Googleがアプリのレビューを開始し、必要な場合はさらに連絡が来るという流れになります。
要するに:
Google Fit APIや個人的、内部的、テスト段階でのアプリでないことを確認した上で、メールに返信してレビューの開始を求めるという手順です。
Google Fit APIは、Googleが提供する健康およびフィットネス関連のデータを管理・追跡するためのAPIです。このAPIを使うと、アプリケーションやデバイスがユーザーの身体活動、運動、心拍数、睡眠などのフィットネスデータを取得・記録できるようになります。
Googleは2024年5月1日からGoogle Fit APIの新規確認リクエストを受け付けないと発表しています。つまり、新たにGoogle Fit APIを使いたいアプリはこの日以降、Googleの確認を受けることができなくなるということです。
Google Fit APIの機能が停止するわけではありませんが、新しいアプリの登録や、APIスコープの使用に関する承認が得られなくなるため、今後の使用に制限がかかる可能性があります。
cat /proc/mdstat [~] # cat /proc/mdstat
md1 : active raid5 sda3[0] sdb3[1] sdc3[2]
585583680 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[===>.................] resync = 20.0% (117116736/585583680) finish=50.0min speed=195000K/secresync 部分でリビルドの進行状況と速度が確認できます。 mdadm --detail /dev/md1/dev/md1 は対象のRAIDデバイス名に置き換えてください。リビルド速度は、システム全体または特定のRAIDアレイごとに設定できます。
cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_maxspeed_limit_min: リビルドの最小速度（KB/秒）speed_limit_max: リビルドの最大速度（KB/秒） echo 100000 > /proc/sys/dev/raid/speed_limit_min echo 10000000 > /proc/sys/dev/raid/speed_limit_maxcat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_maxcat /sys/block/md1/md/sync_speed_min
cat /sys/block/md1/md/sync_speed_max/sys/block/md1/md/ は対象のRAIDデバイスに置き換えてください。 echo 200000 > /sys/block/md1/md/sync_speed_minmd1 の最小速度を200,000 KB/秒（約200 MB/秒）に設定しています。 echo 10000000 > /sys/block/md1/md/sync_speed_maxcat /sys/block/md1/md/sync_speed_min
cat /sys/block/md1/md/sync_speed_maxecho "echo 100000 > /proc/sys/dev/raid/speed_limit_min" >> /etc/rc.local echo "echo 200000 > /sys/block/md1/md/sync_speed_min" >> /etc/rc.localtop や iostat コマンドでシステムの負荷を監視し、必要に応じてリビルド速度を調整してください。smartctl コマンドでディスクのS.M.A.R.T情報を確認し、問題がないかチェックしてください。これらの手順で、RAIDのリビルド状況を確認し、リビルド速度を調整することができます。システムの状態を適宜確認しながら、安全に作業を進めてください。
DHパラメータ（Diffie-Hellman parameters）は、全サイト共通で使用しても問題ありません。実際、以下の理由から、共通のDHパラメータファイルを使用することが推奨されます：
ただし、以下の点に注意してください：
DHパラメータの生成例：
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096この設定方法（全サイト共通のDHパラメータ）は、セキュリティと効率性のバランスが取れた良い選択肢です。サイトごとに個別のDHパラメータを生成する必要はありません。
DHパラメータ（Diffie-Hellmanパラメータ）は、インターネット上での安全な会話を実現するための特別な数字の組み合わせだと考えてください。
日常生活での例えで説明すると：
つまり、DHパラメータは、インターネット上で知らない人と安全に秘密の会話をするための、とても賢い方法を提供する特別な数字のセットです。これにより、オンラインショッピングやインターネットバンキングなどの重要な情報のやり取りを、安心して行うことができるのです。
JITコンパイラ（Just-In-Time Compiler）は、プログラムの実行中にコードを動的にコンパイルする技術です。通常のコンパイラは、プログラムのソースコードを実行前に全てコンパイルしてから実行しますが、JITコンパイラは実行時に必要な部分だけをコンパイルして、すぐに実行します。
JITコンパイラの特徴:
JavaのJVMやJavaScriptエンジン（V8など）で採用されている代表的な技術であり、プログラムの実行速度を向上させる重要な手法となっています。
仮想マシン（Virtual Machine、VM）とは、物理的なハードウェア上で動作するソフトウェアによって仮想的に作られたコンピュータのことです。仮想マシンは、物理的なコンピュータ（ホスト）の上で動作し、独立したオペレーティングシステム（ゲストOS）を実行できます。
仮想マシンの特徴:
仮想マシンには2つの主要なタイプがあります:
JITコンパイラはプロセス仮想マシンの一種であると考えることができます。プロセス仮想マシンは、特定のプログラムやプロセスを実行するための仮想化環境を提供します。JITコンパイラは、たとえばJavaやC#のランタイム環境（それぞれJVMや.NET CLR）などで、バイトコードを実行時にネイティブコードにコンパイルして、効率的に実行する仕組みを提供します。
JavaのJVM（Java Virtual Machine）やC#のCLR（Common Language Runtime）は、仮想マシン上でバイトコード（中間コード）を実行しますが、この仮想マシンがまさにプロセス仮想マシンの一例です。そして、JITコンパイラは、これらの仮想マシンの一部として、バイトコードを実行時にネイティブコードに変換する役割を果たしています。
したがって、JITコンパイラはプロセス仮想マシンの重要なコンポーネントであり、仮想マシン内でプログラムを効率よく動作させるための技術です。
PHPにもJITコンパイラが導入されています。PHP 8.0からJIT（Just-In-Time）コンパイラが正式に導入されました。
これにより、PHPのコード実行時にバイトコードを動的にネイティブコードにコンパイルし、パフォーマンスの向上が期待されます。PHPのJITコンパイラは、通常のインタープリタ型の実行とは異なり、繰り返し実行されるコードやCPU集約型の処理を高速化することが可能です。
php.iniファイルで設定を変更することで有効化できます。ini opcache.enable=1 opcache.jit_buffer_size=100M opcache.jit=tracingjit_buffer_sizeはJITに使用するメモリ量を設定し、opcache.jitでどのJITモードを使用するか指定します（例: tracingやfunctionなど）。OPcache（オペコードキャッシュ）の一部として機能します。PHPコードを解析して生成されるオペコードが、JITによってネイティブコードにコンパイルされます。PHP 8.0でのJITコンパイラの導入は、言語自体の性能を底上げする試みとして注目されていますが、用途によって効果が異なるため、実際のアプリケーションでどの程度の改善が見られるかは、ケースバイケースです。
time dd if=/dev/zero of=tempfile bs=1M count=1000 ; rm tempfile1GBのファイルを作成して何秒かかるか調べる
Alpine Linux 3.19と3.20の主な違いについて説明します。
これらの変更点により、Alpine Linux 3.20は、より多くのアーキテクチャをサポートし、最新のデスクトップ環境やデータベースを提供するなど、機能と柔軟性が向上しています。
[1] https://www.theregister.com/2024/05/29/alpine_linux_320_released/
[2] https://9to5linux.com/alpine-linux-3-20-released-with-initial-support-for-64-bit-risc-v-kde-plasma-6
[3] https://en.wikipedia.org/wiki/Alpine_Linux
[4] https://ja.wikipedia.org/wiki/Alpine_Linux
[5] https://www.reddit.com/r/AlpineLinux/comments/1cydbkz/alpine_320_released_questions/
[6] https://engineering.nifty.co.jp/blog/26586
[7] https://alpinelinux.org/releases/
[8] https://gallery.ecr.aws/docker/library/alpine
[9] https://www.alpinelinux.org/
[10] https://alpinelinux.org/posts/Alpine-3.20.0-released.html
[11] https://alpinelinux.org/posts/Alpine-3.17.10-3.18.9-3.19.4-3.20.3-released.html
[12] https://www.cyberciti.biz/faq/how-to-upgrade-alpine-linux-3-4-to-3-5-xx/
[13] https://hub.docker.com/r/arm32v7/alpine/
[14] https://ja.wikipedia.org/wiki/Linux%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%AF%94%E8%BC%83
[15] https://www.hashicorp.com/blog/installing-hashicorp-tools-in-alpine-linux-containers
[16] https://github.com/alpinelinux/docker-alpine/issues/403
[17] https://discourse.gohugo.io/t/update-the-alpine-package-from-version-3-19-to-3-20/50380
Windowsのディスク管理には、ディスクの構成を効率的に行うためのいくつかのオプションがあります。それぞれのディスクの構成方法について簡単に解説します。
シンプルボリュームは、1つのディスク上に作成される標準的なボリュームです。これは、単一の物理ディスクの空き領域を使用し、ファイルやデータを格納します。特別なデータ保護やパフォーマンス向上はありませんが、最もシンプルで一般的な方法です。
特徴:
スパンボリュームは、複数のディスクにまたがってデータを保存するボリュームです。複数のディスクの空き領域を1つのボリュームとして扱い、データを連続して保存していきます。ただし、ディスク障害が起きるとすべてのデータが失われるリスクがあります。
特徴:
ストライプボリューム（RAID 0）は、データを複数のディスクに分散して書き込むことで、読み書きのパフォーマンスを向上させる構成です。ディスク間でデータを並列に処理するため、速度が向上します。ただし、どれか1つのディスクが故障すると、データがすべて失われるリスクがあります。
特徴:
ミラーボリューム（RAID 1）は、2つのディスクに同じデータをコピーして保存する構成です。1つのディスクが故障しても、もう1つのディスクに同じデータがあるため、データの保護が可能です。パフォーマンス面では、書き込み速度は少し遅くなりますが、読み取りは改善することがあります。
特徴:
それぞれの方式は用途に応じて使い分けることが重要です。データ保護を重視する場合はミラー、パフォーマンスを重視する場合はストライプなど、ニーズに合わせて選択することができます。
VMware ESXiでは、不要になったNFSデータストアを削除する必要があります。削除の前にデータストアが正しくアンマウントされていることを確認する必要があります。この記事では、NFSデータストアを安全にアンマウントし、その後削除する手順を紹介します。
まず、削除したいNFSデータストアがシステムでどのように認識されているかを確認します。SSHでESXiホストにログインし、以下のコマンドを実行します。
esxcli storage filesystem listこのコマンドにより、現在マウントされているすべてのデータストアが表示されます。
例:
/vmfs/volumes/5c4de804-fcdc8470 vm 5c4de804-fcdc8470 false NFS 0 0データストアがまだマウントされている場合は、次の手順でアンマウントします。
SSH経由でESXiにログインした状態で、以下のコマンドを実行します。
esxcli storage filesystem unmount -l <データストア名><データストア名> には、アンマウントしたいデータストアの名前を指定します。例:
esxcli storage filesystem unmount -l vmこのコマンドにより、指定したNFSデータストアがアンマウントされます。
データストアをアンマウントした後、以下のコマンドでNFSデータストアを削除します。
esxcli storage nfs remove -v <データストア名><データストア名> には、削除したいデータストアの名前を指定します。例:
esxcli storage nfs remove -v vm削除が完了したかどうかを確認するには、再度次のコマンドを実行して確認します。
esxcli storage filesystem listリストから削除したデータストアが消えていれば、削除は成功です。
これで、NFSデータストアのアンマウントから削除までの手順がすべて完了します。