はじめに ブランチ名のつけ方の大きな二つの概念。 GitHub FlowとGit Flowについての概要です。 現場によってバラバラだったり、全くこれと違うこともあると思いますが、ベースとして知っておきたくて残してます。 GitHub Flow 基本的にシンプルなこっちが多いみたいです。 master 本番 feature 新機能追加のブランチ Git Flow 複雑であまり使われないらしく、だいたいGitHub Flowでの運用が主になっていることが多いらしい ※masterが一週間に一回しか更新できない。とか大人の事情がある場合につかわれることが多いらしい master 本番 hotfix 軽い修正。masterの修正でmasterとdevelopmentに最終マージされる release 機能追加改修featureの内容をテストし、masterとdevelopmentにマージされる development masterと同じ状態にしておく検証機 feature 新機能追加のブランチ基本的にdevelopmentから派生しマージされる。 さいごに GitHub Flowにhotfix足して～とかそんな感じでプロジェクトごとのケースが多そうです。

はじめに インフラはローカル環境をDockerなどで構築はできますが、詳しくないので、完全個人用のメモです。 間違った情報もあるとおもうので、参考にする際はご注意ください。 用語 OS Linux、windows、iOS、Android、Unixなど。 ちなみにカーネルとは、ハードウェアの管理、プログラムの実行管理、ファイルシステムなど、OSのコアとなる基本サービスをセットで提供するプログラム。 ※カーネル＝Linux=OSみたいな感じになってる Linuxディストリビューション OSとカーネルだけでは動かないのでパック(Linuxディストリビューション)として配布されているもの。 なので、結局Linuxを使うときはLinux環境に好きなディストリビューションをいれる。という形になるみたい。 ※カーネル+アプリケーションという感じ Red Hat系 Fedora（フェドーラ） CentOS(セントオーエス) Red Hat Enterprise Linux(RHEL) Debian系 Ubuntu ※今の主流 Alpine系 軽量でシンプルなディストリビューションらしい ※windowsサーバーにディストリビューションみたいなのはない ※ApaceheやngnixはWEBソフトウェア。WEBページ使うときにディストリビューションに入ってるものという感じのようです。 ※ちなみにApacheのバージョン確認は httpd -v で出来る Linuxフォルダ構造 /bin OSやコマンドが正常に動作するための実行ファイル。基本触らない /boot システム起動時のファイル。そんなに触らない /dev ハードウェア機器(キーボードとか)を表すファイル /etc 設定ファイル /home ユーザのホームディレクトリ。ユーザごとのログインの始まりの場所 /lib OSに必要なライブラリ /media USBなどの外部記憶媒体をシステムで「自動」マウントする。マウントしないと使えない。 /mnt USBなどの外部記憶媒体をシステムで「手動」マウントする。マウントしないと使えない。 /opt chromeなど追加アプリケーションがインストールされる /proc OSのシステムコントロール /root 管理系rootアカウントのホームディレクトリ /sbin 管理系rootアカウントのみ実行できるプログラム (binの管理権限用) /sys OSの現在の状況に関する情報 /usr 全ユーザが共通して利用するプログラムのデータ。 TOPのbinとはべつにここにもbinがはいっていたりする。 ※PCでいうCドライブにツールインストールする。みたいな感じっぽい ※/varとの違い：/varはホストごとの共有できない可変データを入れる場所 /var システム運用中に自動で生成されて、あとから削除されるデータ。ログなどが入る。 プログラムなどのコードもvar/www/source/などに入れたりする。 サーバーの見分け方 Windows ver とか systeminfo とかで情報が返ってくる。 Linuxはコマンド自体使えずエラーになる。 Linux /etc/ に Linuxディストリビューションに応じて設定ファイルがあるのでそれで判断する。 /etc/ で何の設定ファイルがあるか見る CentOS：/etc/redhat-release Fedora：/etc/fedora-release Debian(ubuntu)：/etc/debian_version その他：/etc/issue など なおバージョンの確認は cat /etc/各ファイル名で中身を見てバージョンをみるとOK。 ※例)Debianなら「cat /etc/debian_version」 シェア率はUbuntuが強い 2月Webサイト向けLinuxシェア、Debianが微増 業務で実際に触っていたファイルについて /etc/httpd/conf.d/ssl.conf ドキュメントルート、SSL化のファイルのパスとかログの書き出し場所を記載するファイル。 ssl.conf #80はポート番号でhttpのこと<VirtualHost *:80>DocumentRoot 表示するフォルダのパスServerName ドメイン名RewriteEngine OnRewriteCond %{HTTPS} offErrorLog /var/log/httpd/エラーログのフォルダ名CustomLog /var/log/httpd/アクセスログのフォルダ名 combined env=!nologEnableMMAP OffEnableSendfile Off</VirtualHost>#443はhttps<VirtualHost *:443>DocumentRoot 表示するフォルダのパスServerName ドメイン名SSLEngine onSSLCertificateFile /etc/httpd/conf/SSL証明書ファイル名.crtSSLCertificateKeyFile /etc/httpd/conf/鍵ファイル名.keySSLCertificateChainFile /etc/httpd/conf/中間証明書ファイル名.cerErrorLog /var/log/httpd/エラーログのフォルダ名CustomLog /var/log/httpd/アクセスログのフォルダ名 combined env=!nologEnableMMAP OffEnableSendfile Off</VirtualHost> ※vhost.confとssl.confで設定されてるものや、どちらかだけで設定されてるものもある アクセスログの取り方の例 レンタルサーバーのツールもあるが、生でとる場合は参考先を参照 https://www.homepage-tukurikata.com/access/log.html 参考元より抜粋 一般的には、サーバーの管理画面でアクセスログの保存設定を有効にしたのち、保存期間なども指定することでデータが蓄積されていきます。レンタルサーバーに「log」などのフォルダが作成されている場合、その場所にログが保存されていることが多いです。 以下の内容が1固まりで書いてあるとのこと。 IPアドレス 時間 取得したファイル リクエストしたサーバードメイン ステータス 次のページに行った場合にも同じようにアクセスログが追加されていくため、その時間差からそのページでの滞在時間を調べることができます。 また、最後にアクセスしたページから、どのページで離脱したのかも判断することができます。 実際使うには？ ただし、以下のように情報が多すぎるため、ログとして利用するために、必要な情報だけに絞る仕組みが、結局必要になりそうです。 画像素材などのファイル（.pngや.jpg、.gifなど）、グーグルなどのクローラーによるアクセスもその都度ログに記載されることになります。 そのため、このアクセスログを調べる際は、膨大なデータのなかから画像やクローラーなどのアクセスを取り除いて調べる必要があります。 例えば、１ページ内で画像やCSSなどのファイルを10個使用していた場合、その１ページを閲覧する際にも各ファイルへのアクセスが10個発生してしまうため実際のアクセスよりも10倍のヒット数が計測されてしまいます。 そのため、アクセスログで実際の訪問者のアクセス数を計測する場合、一般的には「.html」などのファイルのみをカウントして１ページビューとカウントすることになります。

はじめに 仕事中に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 > ※このパーツの画像はプロフィール画像が反映します。