はじめに 仕事中にGitHubを使っていたらCRLFとLFの混在が発覚し、対応したのでメモ代わりに記事にしておきます。 CRLFやLFが混在するとダメな理由。 CRLFはwindows系の改行コード LFはLinux(GitHub推奨)の改行コード となっています。 これが混在することで、バッチなどでShellを使ったりする場合の動作に影響がでたり、Windowsアプリでおかしいことになったりと異なる作業環境で影響が出るそうです。 個人的にVS CODEでプログラムを書いてるだけであれば、今まで大きなことは無かったですが、揃えておいた方が後々のトラブルを防げると思い対応しました。 GitHubの改行コードの変換設定について GitHubにはデフォルトで改行コードを自動で変換する仕組みがあり、基本的には何も起こらないそうですが、変換されないケースも稀にあるようです。 改行コード変換機能「git config --global core.autocrlf」の種類は以下の通り。 true:チェックアウト時に「LF→CRLF」、コミット時に「CRLF→LF」 input:チェックアウト時に「変換しない」、コミット時に「CRLF→LF」 false:チェックアウト時に「変換しない」、コミット時に「変換しない」 何にするかはプロジェクトの方針によって違うと思いますが、個人的にはCRLFへの変換を避けLFに統一という意味で input が無難かなと感じています。 改行コード変換機能の設定を確認するコマンドは↓ git config core.autocrlf inputに変更するコマンドは↓ git config --global core.autocrlf input リポジトリにCRLFとLFが混在した場合の解消方法 修正方法については以下の記事様様でしたので、是非ご確認ください。 本当にありがとうございます。 修正方法についてはこちらの記事にすごく助けられました。感謝します。 https://coding-factory.com/news/methodology/cm139 修正コマンドだけ記載しておきます。 1.フォルダ内でCRLFになっているファイルをコマンドで探す。find . -type f | xargs file | grep CRLF2.CRLFになっているファイルがあれば、LFに変換。find . -type f | xargs file | grep CRLF | awk -F: '{print $1}' | xargs dos2unix3.変換後1のコマンドで再検索し確認※変換後に残存があれば再度2をしたら解消しました さいごに 一応乗り越えれて良かったと思います。 いろんなケースがあると思いますが、今後のために備忘録でした。 コマンドについてはChatGPTに聞いたら、すごく良い解説をしてくれますので、お試しあれ！

はじめに 最近サーバーに入って、重いフォルダを圧縮することがそれなりにあるのでメモ。 圧縮コマンド tar cvfz 圧縮後のフォルダ名.tar.gz 圧縮対象のフォルダ名 ※tar：処理しやすいように一つにまとめる方法 ※gz：gzip形式の圧縮方法 解凍コマンド tar xvfz 圧縮後のフォルダ名.tar.gz メモ～！

はじめに 以下の組み合わせで、CSSが反映しない状態になりました。 変更しないといけないことが多かったので、反映するまでに変更した部分だけ記載したいと思います。 原因はLaravel 9からViteになったことが主な原因だそうで、そこに対しての調整になります。 Windows PC Docker php 8.1 Laravel 9 Laravel Breeze この記事がなかったらもっと時間がかかっていたと思います。 本当に感謝です。 https://qiita.com/hitotch/items/aa319c49d625c2a9b65e 反映させるのに必要な変更 docker-compose.yml の php 部分 以下追加 docker-compose.yml ports: - 5173:5173 ※追加場所はVolumeの上にしました。 PHPイメージを読み込む Dockerfile 以下追加 Dockerfile EXPOSE 5173 ※追加場所はRUNの上にしました。 Viteの設定ファイル vite.config.js 以下追加 vite.config.js server: { host: true, // ホットリロード(自動更新)がならない場合追加 hmr: { host: 'localhost', }, // CSSの自動反映がならない場合追加(Dockerだと多少時差がでるかも) watch: { usePolling: true, }, }, ※追加場所はpluginsの下にしました。 ※vite.config.jsはLaravel9をインストールしたらLaravelプロジェクトの直下に自動でできるファイルです。 Laravel Breezeインストールやnpm run dev時にnpmエラーが出る場合 PHPイメージを読み込む Dockerfile node.jsのバージョンが古いとダメみたいです。 16.16.0なら大丈夫とのことで、バージョンアップする必要があります。 Dockerfile内の RUN apt-get install の部分でnode.jsのバージョンを指定するようにします。 以下追加 Dockerfile RUN apt-get install -y node.js npm && npm install n -g && n 16.16.0 ※追加場所はRUNの最後にしました。 ※もし既存でnode.jsのインストールしてる場所があれば消してください。 表示の高速化 viteの仕様上 node_modules フォルダや、 vendor フォルダのバインドを除外しないと、ページを表示するたびにロードに時間がかかるそうです。 以下追加した後は、確かに早くなったので、表示が重たい方はぜひ試してみてください。 docker-compose.yml の php 部分 以下追加 docker-compose.yml #app(phpの部分)のvolumeにバインド除外用の設定を追加#重たいものをバインドしないことによって表示が軽くなる#portsの下に書きました。#「名前付きボリューム:コンテナ内のパス」で書くようです。volumes: - ignore_node_modules:/app/node_modules - ignore_vendor:/app/vendor～～～～～省略～～～～～#ファイルの一番下に除外するために使う、名前付きボリュームを定義volumes: ignore_node_modules: ignore_vendor: PHPイメージを読み込む Dockerfile 以下追加 Dockerfile #バインドしないようにしたので、起動する度に npm と composer の install が必要なので、コマンドで自動でインストールさせるようです。 #これがあると、Docker起動後に毎回手動で composer install と npm install をしなくてよくなり npm run dev だけでよくなります。 ENTRYPOINT [ "bash" , "-c" , "composer install; npm install; exec php-fpm" ] ※追加場所はファイルの一番下にしました。 ※筆者の環境ではこれがなくても install なしで npm run dev だけで動いてる気がしてますが、何かあったらまた更新します。 ※npmやcomposerのコマンドはコンテナ内でしてください。(「docker compose exec サービス名 コマンド」を使ってしたらOKです。) さいごに Docker出来てしまえば、共有が簡単なのですが、それまでの道のりが大変・・ CSSの反映だけだったのですが、仕様上重たすぎる問題もあってかなり時間を使いました。

はじめに GitHubで動作確認用のブランチを作ったときに、あれ？mainとブランチ切り替えてもローカルのソースの状態が変わらない。ってなったので、ファイルの状態をブランチ切り替えで変更できるようになるタイミングを調べました。 結論 ファイルの状態をブランチ切り替えで変更できるようになるタイミングは・・・ git commit したタイミング です。 ブランチをつくっただけ、git add でインデックスに登録しただけでは、ローカルのソースをブランチ切り替えで変更出来ませんでした。 はっきりわかっておけば安心なので、メモがてら残しておきます。

はじめに Google AdSenceのTOPに以下のようなアラートが出ていたため、ads.txt(アズテキスト)というものを設定しました。 ads-txtアラート Gatsby.jsでの設定方法を記載しておきます。 設定方法 Google AdSenceにアクセスして、ベルマークをクリック 「今すぐ修正」をクリック 「ダウンロード」をクリック ads_txt_gatsby.jpg 「ads.txt」がダウンロードされます ./staticフォルダに格納 後はブログを公開すれば完了です。 ads.txtとは 悪い人がなりすましを行い、 広告収入を奪っていく ようなことがあるため、それを 防いでくれる という仕組みです。 せっかくの収益を奪われたら勿体ないですし、ads.txtの設定自体はそんなに難しくないので、設置しておくことをお勧めします。 設定後は反映に時間がかかるため一旦やってみて、しばらくアラートが消えるか様子見をしてみてください。 ※最長で1か月ほどかかることがあるそうです。 ads.txt に関するガイド https://support.google.com/adsense/answer/7532444?hl=ja ads.txt に関する問題のトラブルシューティング https://support.google.com/adsense/answer/9785860?hl=ja&ref_topic=7533328 アップロードが完了したらアラートが消えるまで数週間様子見してください。 お疲れさまでした！

はじめに 基本無料だが以下の範囲に限るようです。 帯域幅が1か月に100GBまで ビルドできる時間が1か月に300分まで Netlify 価格のページ https://www.netlify.com/pricing/?_ga=2.257123211.1889317529.1677054191-99578306.1677054191#teams 帯域幅とは 「どのくらいユーザーにページを表示できるか」というような数値 帯域幅やビルドの利用時間はNetlifyのTOPで見ることができます。 帯域幅やビルドの利用時間確認画面 ※和訳表示の画像です。 ※開発初期でビルドしまくってた時期の画像です。 ※状況によると思いますが、100GBは10万PVでも大丈夫な数値だそうです。 無料枠超えたらいくら？ 早々超えないと思いますが、2023/02時点では以下のようになっているようです。 帯域幅 100GB あたり 55 ドル ビルド時間 500分 あたり 7 ドル 55ドルは高いですね・・ 円安などの影響でしょうか。 万が一超えそうな場合は、スタータープランからプロ版に月額$ 19に加入するのが良さそうです。 プロ版は以下の感じ。 帯域幅 1TB/月 ビルド時間 25,000 分/月 請求を防ぐには？ ヘルプページに以下の記載がありました。 「機能をまったく使用しないことを除いて、従量制の機能の使用に制限を設定する方法はありません」 ＝サイトを削除するしかないみたいです。 Netlify ヘルプのページ https://docs.netlify.com/accounts-and-billing/billing-faq/ クレジットカードを入力しないとどうなりますか? 利用段階で支払情報を登録してない人が大半だと思いますが、支払い通知が来るみたいです。 そのあと、支払いが無い場合は請求通知が続くようです。 早々超えないと思いますが、超えたときはプロに移行か、しっかり支払うのが良いですね。 Netlify ヘルプのページ クレジットカードを入力しないとどうなりますか? その他 個人的にヘルプページを眺めてたら気になった点を簡単に書いておきます。 英語読めないので間違いもあるかもしれません。 現在の使用量が下位レベルの制限を超えている場合、従量制機能の下位レベルにダウングレードすることはできません。(強制的にアップグレードされるということみたいです。) Netlify ヘルプのページ https://docs.netlify.com/accounts-and-billing/billing-faq/ 早々超えないと思いますが、自動課金はNetlifyのデメリットの1つになりそうです。 もし超えたら月2000円くらいのプロ版に入るのが良さそうです。 こうなると毎年およそ一万円前後のレンタルサーバーを借りたほうがよくはなるのか・・

はじめに GatsbyでbuildしてNetlifyでデプロイしたら一部CSSが反映しない！という事象が出ました。 状況は以下の通り gatsby develop 反映してる ⭕ gatsby build → gatsby serve 反映してる　⭕ gatsby build → GitHub → Netlify 反映しない ✖ 解決方法 CSSはきちんと書こうってことでした。 CSS ↓✖NGなパターンbody { font-family : "Helvetica Neue" , Arial , Meiryo ; } CSS ↓⭕OKなパターンbody { font-family : "Helvetica Neue" , "Arial" , "Meiryo" ; } インターネットで信頼している記事を参考に気軽にコピペで使ったのですが、クォーテーションが合ったりなかったりしたら、Netlify側でうまく反映出来ない感じでした。 追記 以下もダメでした。 エラー出ないし。Netlifyに反映しないだけなので厄介なので、今後また発生しだい追記しようかと思います・・・。 CSS ↓✖NGなパターンbody { padding : 8px 0 8px 0 ; } CSS ↓⭕OKなパターンbody { padding : 8px 0px 8px 0px ; } 本当に凡ミスでした。 ただ、Netlifyのデプロイの時だけ失敗する。 という状況で、原因が判明したのも勘で偶然できただけでかなり時間がとられました・・。

はじめに 当ブログはGatsby.jsをカスタマイズしてつくられています。 この記事ではこのブログで記事を書く時に使えるパーツを紹介します。 Front Matter(記事の設定値) マークダウンファイルの 1行目 から記載します。 一番上の「---」が1行目じゃないとエラーになります。 FrontMatter ---title: 'ブログの書き方' #記事のタイトルdate: '2023-02-15' #作成日update_at: '2023-02-15' #更新日 無いとエラーになるので更新日ないときはdateと揃えてください。slug: 'read-me' #url ファイル名と合わせてくださいhero_image: '../images/gatsby-icon.png' #アイキャッチ画像tags: ["その他","マニュアル"] #タグ カテゴリとして使ってもOK--- 目次 h2~h4で書かれた項目を自動で目次として掲載します。 ※この記事のTOPの目次が作成されます。 HTML+Markdown < div class = " toc-title " > 目次 </ div > \```toc\```※\はなくていいです ボックスパーツ 参考 本文 HTML < div class = " boxparts ref " > < div class = " title " > </ div > 本文 </ div > POINT 本文 HTML < div class = " boxparts point " > < div class = " title " > </ div > 本文 </ div > MEMO 本文 HTML < div class = " boxparts memo " > < div class = " title " > </ div > 本文 </ div > 注意 本文 HTML < div class = " boxparts caution " > < div class = " title " > </ div > 本文 </ div > コードブロック javascript console . log ( '' ) ; \```javasctrpt:title=javasctrptconsole.log('');\```※\はなくていいです マークダウンファイルでの画像読み込み 「./src/images/posts」フォルダに画像格納 以下のようにマークダウン形式で読み込み MarkDown ! [ 画像の説明文 ]( ../images/posts/ファイル名.png ) ※HTMLのimgタグでもOK プロフィール画像+吹き出し ここにセリフを書く HTML < div class = " balloon " > < div class = " icon " > </ div > < div class = " talk " > ここにセリフを書く </ div > </ div > ※このパーツの画像はプロフィール画像が反映します。

はじめに ドキュメント管理がされておらず、仕様がわからないツールの対応ばかりをしてきました。 そんな対応はとてもつらく、どうすればこういった辛さを軽減できるのか。 と思い、まずドキュメント管理から、独学ですがUdemyでひとまず学びました。 その内容を個人のメモのために記載しています。 規模も大きく様々なやり方、考え方があるので、あくまで参考程度にして頂ければ幸いです。 手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート https://www.udemy.com/course/it-yugtl/ なお、ドキュメントの記載方法やFMTはチームごとに違うと思います。 表形式、リスト、図、フローチャートなどなどありますが、結果きちんと記載、確認、共有できれば良いので、どんなドキュメントがあればいいのか？も含めてドキュメント作成、運用しやすいものを選定することは必要だと思います。 0から始める場合に、一番いいのはUdemyの講座の原本やチーム内にある原本から作成を始めることだとおもいます。 プロジェクト計画書 このプロジェクトの目的や背景、ルールなどを記載する。 今後知らない人が確認するときに、プロジェクト開始時の意向や全体像がわかるので方針が決めやすくなると思います。 目的・背景 プロジェクトの目的・背景を記載しておく。 どんな意向があったのかがわかるので、今後知らない人が引き継ぐときに作業方針を決めやすくなります。 本プロジェクトのスコープ 全体の登場人物と流れを記載して、このプロジェクトではここまでを見ます。 という責任範囲を明記する。 きちんと責任範囲を定義することで、仕事の対応範囲を明確にします ソリューション(解決方法) 何を使って何を解決するかを記載する。 この時点では一旦アイデアでもOKで、もし決まってるならそれを記載する。 改善方法をざっくりでもリスト化することで、解決したい課題などがわかるので、具体的な手段のたたき台になる マスタースケジュール ガントチャート的に全体のおおまかなスケジュールを記載する この時点は、おおまかだが、仕様確定のタイミングを決めておくのが大切 タスク・成果物一覧 作りたいツールからタスク、作らないといけないドキュメントの一覧を記載する。 タスクの大枠のカテゴリである「要件定義、設計、移行・運用計画、環境構築・開発、テスト」などに各タスク紐づけて書き、それを各書類の利用用途と合わせて書いておくのが良さそうです。 プロジェクト体制 チーム単位でどこまで何をやるか。という責任範囲をきめて記載しておく。 これがないと収集つかなくなるので大切。リーダーまで決めておくとなお良い。 だれに確認するかなどが分からない時に、チーム単位で責任範囲を確認したりできる。 プロジェクトのルール プロジェクト全体をどう進めるかを可視化し、流れを明確化します。 進捗・課題管理を何でするかの概要。 定例MTGの参加チーム、スケジュール、議題の概要。 MTGで課題があった際のチーム連携の流れ、作業方法の流れ などを記載しておきます。 メール件名とかこまごましたのもあるが、必要なものだけかけばOK 特に定例MTGなどの進捗確認方法が大事。 品質管理方針 ドキュメントでもなんでも成果物に対して、誰がチェックを行い、どう品質を保つのか。というルールを書く。 またどういうものがチェック時にひっかかてるのかを把握すると、全体での認識、共有が深まるのでチェック結果の集計が大切とのこと。 ここで正確な成果物できることで、プロジェクトの想定がより安全になる 要件定義 業務のフロー、それを実現するために必要な機能などを書きだし、設計に必要な情報を可視化します。 業務フロー 実際の業務内容をフローチャート形式にして流れや業務を把握し、課題も記載する。 業務単位の箱ができ可視化することで、現在と将来の箱の数がの増減などが見え、業務の効率化が見えるし、システムの箱が増えたらコストが増えるのでどうするか。 などの指標になります。 業務フローがあっているかは運用チームに確認が必要だが、箱の数の増減でフロー効率化が見込めるか。は自分でチェックができます。 基本的に現在のフロー、将来のフローとそれぞれ記載します。 業務フローをもとに作られる、または紐づく主な資料 業務要件一覧 機能要件一覧 総合テストコンディション・シナリオ定義書 運用作業一覧 業務用件一覧 業務フローの業務内容詳細を表で書き業務の要件の一覧を作成する。 フローと揃うことで、流れ＋各業務の概要が整理できます。 以下のようなものを軸に記載します。 業務名 業務概要 担当 変更区分(変更、廃止、同じなのか） 新旧の差異があるならそれも並べて記載 新フローの業務は機能要件をIDで紐づけたらわかりやすい また、業務用件と機能要件など、他資料と関連付けた方が良い場合は、IDなどで紐づけて記載するといいです。 業務用件一覧をもとに作られる、または紐づく主な資料 業務フロー 機能要件一覧 画面遷移図 総合テストコンディション・シナリオ定義書 機能要件一覧 業務を実現するために必要な機能をリスト化した資料。 将来の新業務フローを見ながら実現するために必要な機能をリストで一旦書きだします。 以下のようにかき分けもするそうです。 FitGap分析前：ただの必要機能リスト FitGap分析後：必要機能リストを実際のツールに寄せて、グルーピングし整理したもの 「FitGap分析前」では「画面、処理、IF」などおおまかな区分わけまでしておくといいみたいです。 書きだした後は業務用件一覧の新ツール関連機能と紐づけると、どの業務にどの機能が使われるのかが、わかるようになります。 ※IF=インタフェース＝外部連携のシステムのこと 機能要件一覧をもとに作られる、または紐づく主な資料 業務用件一覧 機能配置図 テーブル一覧 画面遷移図 画面項目定義書 処理概要定義書 単体テストコンディション定義書 機能配置図 機能要件を参考にどんなシステム(環境)でどうつながっているのか？フローで記載する。 例）Web、メールサーバがそれぞれあり、それがどういうシステムと繋がってるのか？など これがあることで、システムの全体像がつかめます。 また、現在と今後がかけると比較もできていいそうです。 機能配置図をもとに作られる、または紐づく主な資料 テスト計画書 結合テストコンディション・シナリオ定義書 インタフェース(IF)一覧 どんな外部システムとどんなタイミングで連携するのか どんなプロトコルで接続する、データ形式でやりとりするのかなどを書きだす。 このIF一覧をもとにその担当とやりとりするので、システムを漏らさずに記載するのが必要。 なお、この値を～みたいな細かいことは後の設計で記載するので、システムの概要くらいの内容でいいとのこと。 インタフェース(IF)一覧をもとに作られる、または紐づく主な資料 IF項目定義書 機能要件一覧 ライセンス一覧 外部ツールなど契約が必要なものをまとめる。 時間がかかる契約もあるので、キチンと記載する。 開発用のPCとかそういうもの含めて調達しないといけないものを記載する。 非機能要件も考慮しないといけないとのこと テーブル一覧 自分たちが作成、利用するデータベースのテーブルを対象に表で概要を記載する。 作成、利用しないテーブルはキリがないし、そのテーブルが変更になったら資料も修正しないといけなくなるので書かなくていい。 正確な情報にすることが大切。 テーブル一覧をもとに作られる、または紐づく主な資料 テーブル項目定義書 ER図 ER図 データベースのテーブルの関係性を示す図を作成する。 ER図は以下から押さえておくとOK 〇：0 |：1の関係 三本線：多の関係 いろんな作成ツールもありますし、さらなる詳細は必要に応じて調べてみてください。 画面遷移図 業務用件、機能要件作成後に新フローに沿ってフローで作成する画面の遷移図 ER図と画面構成図があれば開発ボリュームはある程度図れるとのこと。 なお、既存の仕組みをそのまま使う場合は作成必須ではない。 非機能要件 業務フローに必要な機能以外の要件を書きだす。 通常時、障害時、セキュリティ、メンテナンス、運用、保守などなどかなりたくさんの項目があり、広範囲で想定しないと書けないので、作成難易度はかなり高い印象でした。 また、これも業務やチームに寄って内容や形式が異なりそうなので、既存フォーマットがある場合はそれに沿って作成。 ない場合はIPAなどを参考に基礎を作成するのが良さそうな印象でした。 システム構築の上流工程強化（非機能要求グレード） ※参考ファイル 「06_活用シート.xls」 （非機能要求グレード本体（日本語版） の一括DL（zip）をDLすると入ってます） 設計 要件定義からツールを作成するための資料を作成します。 設計書を作成すれば、あとは開発するだけでOK。という状態にすることが理想。 IF項目定義書 要件定義で決めたIF一覧から、どんなURL？どんな項目？といったものを決める。 リクエスト、レスポンスの値について記載するが、これはDBのテーブル構造と同じ内容になるはずなので、きちんと決めておくのが良い。 テーブル項目定義書 要件定義で作成したテーブル一覧のテーブルごとのカラム情報などの詳細を記載する 既存の物や把握できないものは記載せずに、作成する分だけ記載するという判断でもOK。 正確な情報を記載することが大切。 テーブル項目定義書をもとに作られる、または紐づく主な資料 テーブル項目定義書 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける 画面項目定義書 機能要件一覧から作成した画面とその構成、処理、項目の詳細情報を記載する。 画面の処理や仕様が分かればOKなので、以下のような情報を記載します。 既存画面がある場合は画面のキャプチャー画像 新規画面の場合は簡単な図形で画面のパーツ構成が分かるように記載 画面の遷移元、遷移先 画面項目（テーブル項目定義書と同じように書く） 処理概要として、この画面の処理の内容、トリガー、リクエスト、エラーなどを記載 ※処理概要は別ファイルの「処理概要定義書」に記載してもOK これを見て画面ごとに構成、処理の内容が分かるようにすることが大切。 画面項目定義書をもとに作られる、または紐づく主な資料 機能要件一覧 単体テストコンディション定義書 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける 処理概要定義書 ※画面項目定義書に書けない処理を記載する 標準パラメータ定義書 クラウドシステムやパッケージの機能を使う場合に作成する。 利用に際して設定した項目の値を記載し、今後のために情報を残しておく。 処理概要定義書 機能要件一覧のIDと紐づけて、機能詳細を記載する。 画面項目定義書で処理概要もあるが、どっちかにかけばOK 分かりやすさ重視。プログラム書くときに仕様がわかりやすいように記載する。 主に以下が分かれば良さそうです。 トリガー リクエスト、レスポンス 処理内容 エラー これを見て処理の内容が分かるようにすることが大切。 処理概要定義書をもとに作られる、または紐づく主な資料 単体テストコンディション定義書 機能要件一覧 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける コード定義書 データベースやプログラム内の値をコードで管理する場合に記載する。 データをコードで管理する事で名前の変更に耐えれるが、ぱっと見わからなくなるので設計書にかいておく 使われる場所がわからないといけないので、テーブル項目定義書、画面項目定義書でIDでつながるように紐づけて書いてあげるのも大事。 コード定義書をもとに作られる、または紐づく主な資料 テーブル項目定義書 画面項目定義書 環境設定定義書 インフラ情報を管理するために必要な情報を記載する。 環境構築時に設定した値を記載し、今後確認できるようにしておく。 テスト 設計書から作成したツールのテストをする場合に必要なドキュメント。 ポイントはプログラムからつくるのではなく、ドキュメントから作成するという点。 ドキュメントにプログラムを合わせていくのが大切です。 テスト計画書 テスト全体の概要などを記載します。 主に以下の内容を記載します。 テストスコープの定義 機能配置図から機能ごとにどんなテストをするのか？を記載します。 フローチャートで単体、結合、統合などを色分けで書くとわかりやすいです。 なお、テストは以下のようなものがあります。 単体テスト 設計書に定義した機能がすべて正常に実装されていることを確認する。 設計書に定義した処理の全パターンを網羅すること 結合テスト IFなど連携先のINとOUTにある機能が、互いに整合のとれた設計になっていることを確認する IF定義書に定義したデータパターンを流通するテストを実施 総合テスト 業務フロー、および業務一覧に定義した業務がすべて行えることを確認する 受入テスト 総合テストと同じようなことを依頼元で行う 開始条件と完了条件 単体テスト、結合テスト、統合テスト、受入テストの開始条件と完了条件を表で記載する。 例えば単体テストの条件なら以下のようなものがあります。 開始条件：全ての開発が終わっている 完了条件：定義した条件をすべてクリアした、不具合の発生頻度が収束した。 基本的に前段階の作業が完全に終わっている、定義した条件をすべてクリアしている、ある程度の期間利用し、不具合の発生件数が収束してきている。というのが基本的な条件になると思います。 テスト実施スケジュール テスト期間とその間の移行リハーサルのスケジュールを記載する。 各フェーズでの重要な条件となることの完了予定も記載しておくのが大事。 また移行リハーサルを統合テスト前に行う。 移行とはデータの移行など旧→新へ移行するときの作業のこと。 障害管理プロセス 障害が発生した際の担当の流れを記載する。 誰が何をするのか？がフローでわかればOK。 テスト実施体制 今回のテストにかかわるチームの関係性が分かるように記載する。 テスト期間中の情報連携 テスト期間中の定例MTGなどどういったサイクル、議題、目標で行うのかを記載しておく 単体テストコンディション定義書 機能単位のテストの条件を書き出し作業用のリストを作成する。 機能要件一覧、画面項目定義書、処理概要定義書を軸に項目、処理機能ごとに記載する。 通常？異常？ 必須？必須じゃない？ 登録、削除、更新はできるか テストに使うデータ など各処理とテストデータを記載していきます。 またテスト時の入力値は最小値と最大値や、機能の条件をが満たせるのが良い。 なお、インタフェース(外部連携)機能は結合テストでするので、ここはあくまで今見てるツールの動作だけでいいOKです。 IFが完成してない場合は、スタブ(値だけ返す仮のインタフェース)を簡単に作成しておく また最大のポイントはプログラムをみて設計書をつくらないこと。 設計書から作成し、設計書どおりに動いてるか複数回数日に分けて確認する。 単体テストコンディション定義書をもとに作られる、または紐づく主な資料 機能要件一覧 画面項目定義書 処理概要定義書 結合テストコンディション・シナリオ定義書 単体テストと違い、複数の処理を組み合わせたテストです。 そのため複数項目を経てOKとなることが多いです。 テストを行うためのテストシナリオ(操作手順ごとにテスト項目を並べたもの)を機能配置図、機能要件一覧を基準に作成します。 コンディションシートで項目を網羅的に書きだし、シナリオシートでそれを体系的記載します。 1つのシナリオで全部しようとすると書けないので、1つずつ書いて、いくつかシナリオを分けて作成します。 入力値などサンプルデータの作り方は単体テストと同じ感じです。 結合テストコンディション・シナリオ定義書をもとに作られる、または紐づく主な資料 機能配置図 機能要件一覧 総合テストコンディション・シナリオ定義書 将来の業務フロー全体を通すテスト、すべての業務用件が実施できるか確認する 業務フローの数だけ、シナリオもできます。 気付けないことがあるので、データは本番に近いのが良いです。 また総合テストでプログラムのバグがでるのはかなりまずいことなので、それがないように前段階のテストはしっかりしておきたい。 出るべきバグは設計や仕様で漏れていたそもそも想定されていないこと。 総合テストコンディション・シナリオ定義書をもとに作られる、または紐づく主な資料 業務用件一覧 業務フロー 障害一覧 テストの結果を表でまとめて記載する。 まとめることで一日あたりの障害数が減ってるかみれたりするし、書く人、直す人が作業しやすくなる。 どのフェーズ？(単体？結合？統合？) 事象 どの段階？(要件?設計?など) 原因 解決方法 などを書いておくと良いです。 障害一覧をもとに作られる、または紐づく主な資料 単体テストコンディション定義書 結合テストコンディション・シナリオ定義書 総合テストコンディション・シナリオ定義書 移行計画 旧システムから新システムに移行する。 または新システムを導入する方法を正確に記載する。 移行計画書 旧システムから新システムに移行、または新システムを導入する方法の計画書。 主に「業務、システム、データ」のカテゴリで流れ、移行方法、懸念事項を把握しながら記載します。 また新規システムだけならいいが、旧システムが絡む場合、移行するデータの選別、仕様を把握+データの不整合が起こらないように慎重に決めないといけないので、 かなり慎重に計画を作成する必要があるので、移行手順を作成し、総合テスト前に移行リハーサルを行うことは必須になります。 移行計画書として作成する主な内容は以下の通りです。 移行方針の概要 業務、システム、データで何をどうして、どう移行するのかの概要 業務上やデータの整合性を保てるような方針にする。 移行対象データ一覧 移行すべきデータをすべて確認し、移行方針、移行方法を記載する 移行スケジュール 移行全体のスケジュール。 結合テストの段階で調査、手順書の作成を行い、総合テストの前に移行リハーサルをするようなスケジュールが良い 移行体制 移行にかかわるチームを記載する 移行手順書 移行計画を実行するために、いつまでに、どういうやりかたで進めるのかを見ただけでできる状態にまとめておく。 旧システムから引き継いで移行する場合は特に複雑化するので、総合テストの前に本番と同じ移行作業をリハーサルしながら作成する。 もっといえば何時何分～何時何分でこの作業をおこなう。というのも書いておいた方が良いみたいです。 テストコンディションと同じように誰が何をしたがわかるようにリストで作成する 運用計画 システム完成後の運用の作業の一覧やマニュアルを作成する 運用作業一覧 システム完成後の運用の作業の一覧を記載する。 例えば、ユーザ登録、削除、障害対応、仕様変更(追加開発)などがあり、項目としては作業項目、頻度、作業概要などを表で記載する。 運用作業マニュアル 運用の作業一覧の業務を見ただけでできるようにする。 定期作業は特に開発できない人たちにやってもらうこともあるので、詳細に手順を記載しておく必要があります。 ドキュメントをみて運用作業、ドキュメント更新ということを徹底する。 なお、運用という枠に開発の改修なども入る場合もあるそうなので、その場合は開発が仕様を把握できるようにドキュメント管理を行うといいと思います。 障害報告書 障害が起こったときにその原因→解決方法をを記載していく。 難しい+スピードが必要な作業で限られた人しかできないので、原因→解決方法を簡潔に記載しておくことで、今後誰でもできるように、または解決しやすくする。 主に以下の内容を残すと良さそうです。 発生事象 発生原因 影響範囲 暫定対応 根本的な原因 本格対応 プロジェクト管理 プロジェクトを管理するための方法、ドキュメントを作成する。 WBS 全部のタスクについて、だれが何をいつからいつで行うのか+進捗がわかるものように管理しておくことをWBSという。 案件が始まるときに作成し、要件定義が決まったらブラッシュアップするのがいいみたいです。 チームによってさまざまだと思うが、ガントチャート的なフォーマットが多いと思います。Backlogなどのツールもあるのでそういったものを使うケースもあると思います。 TODO・課題一覧 WBSの漏れなどの問題、誰かに聞かないとわからないことなどが起こったらそれ課題として表に記載していく。 TODO(やればおわること)や課題(予想されるリスク、懸念)を記載し事前に認識しておくことで事故を防ぎます。 レビューシート 成果物のレビューを表で残す。 成果物のチェックレビューを残すことで、間違いが多いものなどの傾向を知ることができる さいごに 学んだ感想としては、この書類があり、きちんと見る方法、更新方法を教えていければ、仕様の引継ぎ把握は格段にしやすくなるのではないかと感じました。 一方でドキュメントの量がとても多く、整合性を保つ難しさも感じたので、プロジェクトチーム全体でどれだけ意識をたかめてドキュメントの見方の説明、作成、更新していけるか。が非常に難しく、大変なことだと思いました。 ひとりでは作成できないので、繋ぎ、まとめ役、各専門家の連携は必要だと思います。 またどちらにしてもプログラム内にはちゃんと実装背景、理由などコードから読み取れないことをコメントで残しておくことも必須だと感じました。 率直に量が多い！！大変だ！！ 開発より時間をかけるというのもうなずけます。 目次だけでも見るの大変ですが、全体をつかみたいときは目次見てください。 今回勉強して一番響いた言葉は 「プログラムからドキュメントを作成しない。ドキュメントにプログラムをあわせる」 でした。 本当大事。

はじめに Dockerで個人的によく使うコマンドを目的別に記載します。 基本的にDockerのコマンドではなく、docker compose のコマンドを利用しています。 最初は**「コンテナ起動～停止」**だけ使えればいいと思います。 自分でDocker構築したり、その他情報がしりたくなったら他のコマンドが必要になる感じです。 どのコマンドも cd で docker-compose.yml があるフォルダに移動して、行うことは共通になります。 別記事でDockerで以下の環境を作成するチュートリアル記事も書いてますので、よかったら見てみてください。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認 【Docker】#6 LaravelのDB設定、確認 【Docker】#7 phpMyAdmin表示確認 【Docker】#8 できてる環境の確認 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 コンテナ起動～停止 普段一番使うコマンドです。 Dockerの設定ファイルが出来たらあとは環境を起動、停止して開発をすすめるという流れになるので、基本的にこれしか使わなくなります。 ※コマンドじゃなくても、Docker Desktopアプリでもスタート、停止できます。 1.コンテナ起動 以下のコマンドを実行するとコンテナが起動します。 docker-compose up -d ※このコマンドはビルド( docker-compose build )+スタート( docker-compose start )を行っています。 ※ -d はバックグラウンド実行になり、コマンドプロンプトの占有を防ぐためのオプションです docker-compose up 2.コンテナ停止 稼働中のコンテナを停止します。 docker-compose stop ※コンテナの削除はしません。 ※docker-compose start または docker-compose up で再起動できます ちなみに筆者的には stopより down(コンテナ、イメージ削除+停止)が良い と思っています 。 docker-compose down 理由は下の「注意」を参考にしてください。 ■「docker-compose stop」ではなく「docker-compose down」を使う理由 複数の環境を切り替えて使う場合、サービス名やポートの重複、キャッシュなどで、 うまく起動しなくなる場合があります 。 その場合は「docker system prune」で全体のお掃除をして解消も出来ますが、別環境をup(起動)するたびに全てインストールしなおしなので、初回起動時に めちゃくちゃ時間がかかります 。 また、別環境使うときに以前使ってた、もしくは影響してる環境を覚えてない場合は、それを探してdownしないといけなくなります。 なので、筆者としては基本的にstopするときは常に「docker-compose down」を使ったほうが良いと思っています。 docker-compose stop(公式) docker-compose down(ページ内アンカー) 起動しているコンテナの一覧を確認 今起動しているコンテナを確認したい場合は以下のコマンドで確認できます。 docker-compose ps ※コマンドじゃなくても、Docker Desktopアプリでも確認できます。 ※起動していないコンテナも確認したい場合は -a オプションを使います。 docker-compose ps コンテナ内でコマンドを実行したい docker-compose exec サービス名 実行したいコマンド ※このコマンドは docker exec と同じです ※ -it オプションでコンテナの中の環境に入って、対話モードでコマンドできるようにできます。抜けるときはexitでOKです。 例）コンテナ内で bash (コマンドプロンプトの一種)を起動して、MySQLに接続するコマンド $ docker-compose exec DBのサービス名 bash[db]:/$ mysql -u ユーザ名 -p// パスワードを求められるので入力//データベース指定[db] mysql> use database;//テーブル表示[db] mysql> show tables; docker-compose exec イメージからコンテナ(環境)を作り直したい 1.今いるディレクトリに対してイメージ、コンテナの削除 Dockerの設定ファイルを書き直したり、イメージをつくりなおして再度コンテナを起動したい場合は、よく以下のコマンドを使い削除します。 docker-compose down↓docker-compose up -d --build ※ --build：コンテナを開始前にイメージを構築する docker-compose down キャッシュ等でうまく更新できない場合は「docker-compose down --rmi all --remove-orphans」で綺麗にしてから「docker-compose up -d」をすると解決すると思います。 docker-compose down --rmi all --remove-orphans このコマンドを使うことで、Docker内のキャッシュなどの影響で起こるよくわからないエラーなども回避しつつ、再構築ができます。 要約すると以下のことを行います。 今いるディレクトリに対してコンテナ停止、削除、ネットワーク、イメージ、未定義のコンテナを削除してきれいにする 各オプションなどについて↓ docker-compose down は docker-compose up で作成したコンテナとネットワークを停止、削除 –rmi all オプションで全イメージを削除 –remove-orphans オプションでComposeファイルで定義していないサービス用のコンテナも削除 「docker system prune」との違いについて このコマンドはディレクトリ関係なく、使われてないイメージ、コンテナ、ネットワークを削除（prune）するコマンドです。 Docker全体に対するお掃除という感じです。 ■ボリュームについて ※いつか別記事移行するかも… Dockerはメモリ上で動くため、コンテナを削除した時点で作業した内容が消えてしまいます。 そのためボリュームという機能をつかってファイルやDBの情報を永続化し消えないようにします。 主に以下のような用語があります。それぞれ利用します。 ・バインドマウント ローカルのファイルをコンテナ側を同期(マウント)します(=コンテナに変更を自動反映) ※作業ファイルはローカルに残ります 削除タイミングは自分でフォルダを消すときになります。 ・名前付きボリューム DBのデータなどを残したいときに使います。 Docker内で保持されるので、一見するとどこに行ったかわからなくなりますが、Docker Desktop アプリや docker volume ls コマンドで確認できます。 削除タイミングは docker-compose down や docker system prune で ボリュームオプションを指定したタイミング です。 ※匿名ボリュームというのもありますが、基本的に名前付きがつかわれます。 ボリュームの実際の書き方は以下のdocker-compose.ymlのコメントを参考にしてください。 docker-compose.ymlを作成 ボリュームはしれっとたまっていくので定期的にお掃除する必要があります。 作業データがいらなくなったときに、以下どちらを使い用途に応じて削除するといいと思います。 1. 今いるディレクトリに対してコンテナ停止、削除、ネットワーク、イメージ、ボリューム、未定義のコンテナを削除する docker-compose down --rmi all --volumes --remove-orphans 2. ディレクトリ関係なく、起動していない、ボリューム、イメージ、コンテナ、ネットワークを削除（prune）する docker system prune --volumesまたはdocker volume prune 2.コンテナ再起動 docker-compose up -d 【おまけ】その他のコマンド 必要になったときに見てください。 基本は上記の内容で事足りると思います。 コンテナ停止 docker-compose stop コンテナ削除 docker-compose rm ※起動しているコンテナは削除できません コンテナ再起動 docker-compose restart 今あるイメージを確認 docker images ※docker compose ではなく docker のコマンド 対象のイメージを削除 docker rmi イメージ名 or イメージID ※docker compose ではなく docker のコマンド ※コンテナがあるイメージは削除できません ※強制削除もあるが今回はなし docker-compose.ymlで管理されているサービス1つを指定してコマンドを実行する docker-compose run サービス名 コマンド ※ビルド前でも実行可能なコマンド。一時的にコンテナ作成してコマンドを実行できる 例） docker-composeのvolumeでフレームワークのフォルダが事前に必要な場合に 先にフレームワークのインストールだけしておく際などに使える。 フォルダが先にないとエラーが出たりする この記事でLaravelをインストールするときに使ってます。 2.Laravelのインストールコマンドを実行 Docker コンテナの詳細情報確認 docker inspect コンテナ指定 ※docker compose ではなく docker のコマンド ※よくみるのは mount ：どこのvolumeをマウントしてるか config：だれがもってるかとか、環境変数とか、Cmdとか network setting：コンテナのUPAddress(ホストからつなげるIP)の確認もできる ※IPは docker-compose ps のコンテナ一覧でみることが多いです イメージの履歴を確認 docker history イメージ名:タグ ※docker compose ではなく docker のコマンド ※他人が作ったイメージの更新履歴を知りたいときに使う Dockerコンテナのログを出力 docker logs コンテナ指定 ※docker compose ではなく docker のコマンド ※アクセスログ、不明な停止の原因を確認した時に使う ※リアルタイム監視でログをだすにはオプション -f を使います。 作業中をリアルタイムで追えるようになります Docker 全体のお掃除 docker system prune ※docker compose ではなく docker のコマンド ディレクトリ関係なく、イメージ、コンテナ、ネットワークを削除（prune）する ボリュームはデフォルトでは削除されないため、–volumes フラグを使う必要があります。 ※使用中のものは消されないのでstopしないといけない ※docker compose ではなく docker のコマンド ※オプション -a 既存のコンテナ～使われていないイメージすべてを削除する なぜかイメージが消えない時はこれ。全部消えるので注意 使用していない Docker オブジェクトの削除（prune） さいごに 正直自分のためのメモでもある！おまけは覚えなくていいし、困ったら見てください。 ちなみにdockerコマンドとdocker-composeコマンドは同じことができるコマンドがあったりするので、好きな方を使うでOKです。