名前</th>	種類</th>	ポート(HTTP)</th></tr></thead>
docker-private</td>	docker(hosted)</td>	5001</td></tr>
docker-hub</td>	docker(proxy)</td>	-</td></tr>
docker-group</td>	docker(group)</td>	5000</td></tr> </tbody></table> それぞれの作成時の設定内容は以下</p> docker-private</h4> docker(hosted)で作成</li> HTTPをチェックしポート番号を指定 (5001)</li> Enable Docker V1 API:</code> をチェック</li> </ul> docker-hub</h4> docker(proxy)で作成</li> Remote storage:</code> に https://registry-1.docker.io</code> を指定</li> Docker Index:</code> は User Docker Hub</code> を選択</li> Enable Docker V1 API:</code> をチェック</li> </ul> docker-group</h4> docker(group)で作成</li> HTTPをチェックしポート番号を指定 (5000)</li> Member repositories:</code> に先に作成した二つのリポジトリを追加</li> Enable Docker V1 API:</code> をチェック</li> </ul> ※ 私の環境では Enable Docker V1 API:</code> をチェックしてないと push できませんでした。</p> firewall設定(追加)</h3> リポジトリ作成後は NXRMをインストールしたホストで 5000/tcp, 5001/tcp を許可する。</p> firewall-cmd --add-port</span>=5000/tcp</span> --permanent --zone</span>=public </span>firewall-cmd --add-port</span>=5001/tcp</span> --permanent --zone</span>=public </span>firewall-cmd --reload </span></code></pre> インストール手順(クライアント)</h2> docker 環境を構築してください。</p> 非TLSのリポジトリに接続させるためには設定が必要です。</p> 環境</h3> 以下環境で確認しています。</p> OS : CentOS8</li> Docker : 19.03.8</li> </ul> 疎通確認</h3> curlでNXRMにリクエストを投げた際に、Dockerリクエストではない旨レスポンスが返ってくればOK。</p> curl</span> http://nexus_hostname:5000/ </span><html> </span><head> </span><meta </span>http-equiv</span>="</span>Content-Type</span>" </span>content</span>="</span>text/html;charset=utf-8</span>"</span>/</span>> </span><title>Error </span>400</span> Not a Docker request</title> </span></head> </span><body><h2>HTTP </span>ERROR</span> 400 Not a Docker request</h2> </span><table> </span><tr><th>URI:</th><td>/</td></tr> </span><tr><th>STATUS:</th><td></span>400</span></td></tr> </span><tr><th>MESSAGE:</th><td>Not </span>a</span> Docker request</td></tr> </span><tr><th>SERVLET:</th><td>-</td></tr> </span></table> </span><hr><a </span>href</span>="</span>http://eclipse.org/jetty</span>">Powered </span>by</span> Jetty:// 9.4.30.v</span>20200611</span></a>< hr/> </span> </span></body> </span></html> </span></code></pre> daemon.json の設定</h3> daemon.jsonを作成し、Dockerの設定を記述します。</p> vi</span> /etc/docker/daemon.json </span></code></pre> TLS化していないリポジトリを利用する場合 insecure-registriesで指定する必要があります。 ※毎回コマンドラインで指定する事も可能ですが、面倒なのでdockerのdeamon設定がお勧め。</p> insecure-registries</code> で、NXRMで追加したレジストリを追加してください。</p> { </span> "</span>debug</span>": </span>true</span>, </span> "</span>insecure-registries</span>": ["</span>nexus_hostname:5000</span>", "</span>nexus_hostname:5001</span>"] </span>} </span></code></pre> ※ミラー設定も行った場合の設定は下で記載しています。</p> daemon.json作成後はDockerデーモンを再起動。</p> systemctl</span> restart docker </span></code></pre> Dockerイメージの登録(push)</h2> NXRMにログイン</h3> ユーザ / パスワードは NXRMのユーザを指定します。</p> docker</span> login nexus_hostname:5000 </span>docker</span> login nexus_hostname:5001 </span></code></pre> 実行すると Username, password 入力を求められるので、自身のアカウントでログインして下さい。</p> 実施時に WARNING 出力されますが、Login Succeeded</code> になれば login 成功です。 ※コマンド実行後は ~/.docker/config.json</code> に認証情報が記録されます。</p> push</h3> hosted リポジトリに pushします。</p> docker</span> tag イメージ名:バージョン nexus_hostname:5001/イメージ名:バージョン </span>docker</span> push nexus_hostname:5001/library/イメージ名:バージョン </span></code></pre> 何故か、library</code>付けないとpull時点で 404(NOT FOUND)になった。</p> ※おそらく docker-hub と同じように accountname/imagename:version</code> のようなタグ付けをしないと駄目な気がする。公式イメージの場合には accountname部分がないが、こういうタグ付けの場合には library 以下になっている風。実際に公式mariadbを落としてきてproxyリポジトリに格納されているのを見ると name = library/mariadb</code> となっている。</p> pull</h3> push したイメージが取得できるか確認取得先は登録したhostedではなくhostedとproxyをまとめているgroupリポジトリを指定しています。</p> docker</span> pull nexus_hostname:5000/イメージ名:バージョン </span></code></pre> ミラー設定</h2> ここまでの設定で、独自に作成したDockerイメージをリポジトリサーバに登録(push)、及び、取得(pull)できる事が確認できましたが、この状態では独自イメージと外部(docker-hubでホストされている)イメージを透過的に扱う事ができません。</p> これを透過的に扱えるように設定を変更します。</p> 具体的には、自分でホストしているイメージ取得の場合でも以下のように、リポジトリサーバ:ポートを指定しないで取得できるようにします。</p> ※push時にはリポジトリサーバ:ポートを指定しなければいけません。</p> docker</span> pull イメージ名:バージョン </span></code></pre> docker では、registry-mirrors を利用する事で、docker-hubのミラーとして設定できるので、作成したgroupリポジトリを設定する事で対応可能なはずですが、</p> ミラーサイトに対して正しく認証情報が渡されない問題があるため、仕掛けが必要になります。</p> 参考 : registry-mirrorsが機能しない</a></p> 対応方法としては、 Docker is not passing auth informations when pulling from a mirror registry #30880</a> にある認証情報をNginx(proxy)側で上書きしてNexusにアクセスさせる方法を採ります。</p> nginx設定の編集</h3> 最終的に以下のような設定にしました。</p> events </span>{ </span> worker_connections 1024; </span>} </span> </span>http </span>{ </span> </span> proxy_send_timeout 120; </span> proxy_read_timeout 300; </span> proxy_buffering off; </span> keepalive_timeout 5 5; </span> tcp_nodelay on; </span> </span> log_format upstreamlog </span>[</span>$</span>time_local</span>] </span>$</span>remote_addr</span> - $</span>host</span> - $</span>upstream_addr</span> - $</span>request</span>; </span> access_log /var/log/nginx/upstream.log upstreamlog; </span> </span> server { </span> listen *:80; </span> server_name www.example.com; </span> </span> </span># allow large uploads of files </span> client_max_body_size 1G; </span> </span> </span># optimize downloading files larger than 1G </span> </span>#proxy_max_temp_file_size 2G; </span> </span> location </span>~</span> ^/(v1\|v2)/ { </span> if ($</span>authorization</span> = '') { </span> set $</span>authorization </span>"</span>Basic XyzAbCdefg1234567890Mzk2Zi00NWYxLWJiNjYtN2ExOWRkM2EyOTVk</span>"; </span> } </span> proxy_pass http://127.0.0.1:5000; </span> proxy_set_header Authorization $</span>authorization</span>; </span> proxy_set_header Host $</span>host</span>; </span> proxy_set_header X-Real-IP $</span>remote_addr</span>; </span> proxy_set_header X-Forwarded-For $</span>proxy_add_x_forwarded_for</span>; </span> proxy_set_header X-Forwarded-Proto $</span>scheme</span>; </span> proxy_set_header X-Forwarded-Port $</span>server_port</span>; </span> } </span> </span> location / { </span> </span># Use IPv4 upstream address instead of DNS name to avoid attempts by nginx to use IPv6 DNS lookup </span> proxy_pass http://127.0.0.1:8081/; </span> proxy_set_header Host $</span>host</span>; </span> proxy_set_header X-Real-IP $</span>remote_addr</span>; </span> proxy_set_header X-Forwarded-For $</span>proxy_add_x_forwarded_for</span>; </span> } </span> } </span>} </span></code></pre> リポジトリアクセスする場合 /v1 or /v2 で始まるURLにアクセスされるので、この場合にgroupリポジトリに転送します。この際、proxy_set_header Authorization ...</code> で認証情報を設定しています。</p> $authorization</code> に設定する基本認証の値は以下のようにして生成可能です。</p> echo </span>-n </span>'</span>username:password</span>' \| </span>base64 </span></code></pre> また、上記設定では実際の転送先を確認するためupstreamlog</code>を出力するように設定しています。</p> 上述した、library</code>を付けてpushしないと pull できなかった問題はこのログの確認で気づきました。 pushは出来たがpullできない場合で、404が発生している場合、dockerクライアントがmanifestsを取得するURLがpushした先と異なっている可能性があります。この場合にはuplstreamlogの確認で解決するかもしれません。</p> nginx再起動</h3> 設定に問題ないか確認し、</p> nginx -t </span></code></pre> 問題なければ再起動します。</p> systemctl</span> restart nginx </span></code></pre> クライアント側設定</h3> /etc/docker/daemon.json を以下に書き換えます。 registry-mirrors</code>、及び、insecure-registries</code> で nexusのホストを指定しています。</p> { </span> "debug": true, </span> "insecure-registries": [ </span> "nexus_hostname", </span> "nexus_hostname:5000", </span> "nexus_hostname:5001" </span> ], </span> "registry-mirrors": [ </span> "http://nexus_hostname" </span> ] </span>} </span></code></pre> トラブルシュート</h2> ミラー設定が一番ハマりました。</p> 問題発生時には以下内容の確認をお勧めします。</p> docker(クライアント側)ログ私の構築した環境ではsyslog(/var/log/message/)に出力</li> nexus repository managerのログ /opt/sonatype-work/nexus3/log</code> が出力先です。</li> nginxのログ proxyしている場合、上述のupstreamlogも利用しましょう。</li> </ul> リクエスト先が正しくない</h3> library</code>付けずにpushした場合、hostedリポジトリに以下のような構造でpushされました</p> /v2 </span> \|- blobs </span> \| \|- sha256:..... </span> \| \|- sha256:..... </span> \| \|- sha256:..... </span> \| \|- sha256:..... </span> \|- image_name </span> \|- manifests </span> \| \|- sha256:... </span> \|- tags </span> \|- latest </span></code></pre> この状態でミラー設定を行い docker pull image_name</code> するとdockerログには以下のエラーが出力</p> Oct 13 02:36:40 localhost dockerd[17647]: time="2020-10-13T02:36:40.054981034-04:00" level=info msg="Attempting next endpoint for pull after error: Get https://nexus_hostname:5000/v2/library/image_name/manifests/latest: unauthorized: access to the requested resource is not authorized" </span></code></pre> /v2/library/image_name/...</code> にアクセスしている(らしい)事が判りました。 (実際はこの前にupstreamlogで気づく)</p> 以下でpushし直した後、pullできる事を確認しました。</p> docker</span> push nexus_hostname:5001/library/image_name:latest </span></code></pre> docker</span> pull image_name </span></code></pre> 参考</h2> Using Nexus 3 as Your Repository - Part 3: Docker Images</a></li> Installation</a></li> Configuring Blob Stores</a></li> NFS v4の設定内容まとめ</a></li> registry-mirrorsが機能しない</a></li> Docker is not passing auth informations when pulling from a mirror registry #30880</a>"</li> </ul> 陶器のウミウシたち 2026-09-22T00:00:00+00:00 動機</h2> 亡き妻 ( NYC SVA 卒。肺腺癌で夭折 ) がポタリーペインティングを行っていたのだが、私の方ではポタリー粘土で形を作って、いくつかの陶器フィギュアを作っていたことがあった。</p> ウミウシ。</p> ウミウシの写真集を見て、美しさに感動した頃の作。</p> </p> </p> その後</h2> 妻のポタリーの個展などに出品していたのだが、いつのまにか全部いなくなってたのだ。買ってくれた人の下に今もいるかもなのだ。</p> ウェディングドレス 2026-09-22T00:00:00+00:00 なぜ作った？</h2> 亡き妻 ( NYC SVA 卒。肺腺癌で夭折 ) は結婚式で自分がイメージしたドレスが来たかったらしく、そのイメージに近いドレスを作製したのだｗイメージは妖精。普通のウェディングドレスとは異なる、胸から一枚の布がふわっと広がる感じ。前部分は膝上でくるっと内に巻いている感じで、後ろは普通のウェディングドレスと同様にドレープが自然に流れる感じ。</p> ドレス選びの時に見たのだが、イメージに合うようなドレスは無し。という事で作ることに(私が..)</p> 材料調達</h2> 日暮里繊維街に布を探しに行き、トマトで布をゲット。パニエがないと綺麗なラインにはならないのでパニエも作成(こっちの方が時間がかかった記憶がある)。</p> </p> </p> このドレス、妻の友人が「着たい！」とかで妻は太っ腹にあげてしまったのだ。</p> ボディバッグ 2026-09-21T00:00:00+00:00 亡き嫁にもらったボディバッグがボロボロになったので作った自作ボディバッグ。本体部分はボロボロになったのだが、ベルト部分は全然問題なかったので、ベルト部分は再利用している。革はハンズでたまたま良さげなの売ってたのでそれで作成。</p> 底部分は切り替えて黒の革を利用。革部分は手縫い。内袋はミシンで。</p> </p>

mosaos

スピーカー保護回路基板を改造する

2026-09-28T00:00:00+00:00

スピーカー保護ボード</h2>
Aliexpress を眺めていたら、オーディオスピーカー保護ボードなるものを発見してポチったのだ。

AC 12-16V となっているもので、組み立て済みではなくてキット(組み立て済みも売ってる)。
似たようなものは結構売っていたのだが、そこそこレビューもついているものを購入した ( Aliexpress Link</a> を参照 ) 。
２個買って無事に２個到着。
自作デジタルアンプがあるので、これに組み込もうと思ってたのだが、上でも書いたように AC(交流) 12V-16V 用。
そのままでは使えないだろうとは思っていて改造前提で購入。
基板は以下。 
基板、及び、完成写真からは、まず以下のことが判った。

AC入力を整流(DCに変換)するためにブリッジダイオード がある ( 基板の `A1</code> ) デジタルアンプなどは DC(直流) なので不要</li>`
ブリッジダイオードの後に三端子レギュレータ がある ( 基板の L7812CV</code> ) これでAC12-16Vから直流にしたものを12Vにしている。DC12V 以下で動作するデジタルアンプであれば不要 ※ ACV × √2</code> が理論値なので AC12V -> 約DC17V。ダイオードの電圧降下もあるので、実際は 15V程度になる。</li> </ul> なので、これらはスキップしてあげれば直流で動作するアンプでも動作するはずと予想。 ※ ブリッジダイオード前に DC12V を入れる事も可能なのだが、ブリッジダイオード+三端子レギュレータによる電圧降下によって、回路部分の電圧は9V程度になる -> リレーが安定動作しないになる可能性が高い。 あと、手持ちの PAM8406 で動作させようと DC5V 化も行うために、以下も行うことにした。
リレーの変更
電圧が DC12V -> DC5V になるので、リレーの変更が必要。`SRD-12VDC-SL-C</code> が付いているので SRD-05VDC-SL-C</code> に交換。 SRD-05VDC-SL-C 5PIN, 5PCS</code> を購入 (Aliexpress Link</a> を参照 )</li>`
5V リレーが動作するように抵抗値を変更回路には DC12V ではなくて DC5V が入ることになる。5Vのリレーは上記リレーの製品サイトを見ても判るのだが、必要な電流値 ( コイル電流 ) は以下。 5V : 72 mA</li> 12V : 30mA 電圧も 12V -> 5V に下がっているので、抵抗がそのままだとリレーは全く反応しない可能性が高い。</li> </ul> </li> </ul> 改造</h2> 上記改造を施した基板の写真を最初に示す。 この時点では改造箇所は３か所 (section1 - section3) Section 1</h3> A1</code> 及び L7812CV</code> は取り付けない。</li> 元々は AC</code> 部分に取り付けるターミナルは A1</code> の出力部分 ( +, - が印刷されている ) に取り付けた。</li> 基板パターンを見ると判るが、これだけだと回路に + が入らないので、L7812CV</code> の両端をジャンパワイヤで短絡する。真ん中にあるランドに触れてショートしないようにする事。私はリード線の切れ端とかではなくて、被覆線を用いた。</li> </ul> これで、ターミナルに入れたDCがそのまま回路に入るようになる。 Section 2</h3> 上で書いた 5V リレーが動作するように抵抗値を変更</code> 部分。基板上は 100K</code> になっている。AIに質問した際に、「ここをショートすればリレーが反応する」とか言ってたのだが、トランジスタが死ぬ ので厳禁ｗ。 Section 3</h3> リレーを SRD-12VDC-SL-C</code> から SRD-05VDC-SL-C</code> に交換。 Section 4</h3> この時点では気づいてない。( 後述 ) 動作確認</h2> 100円ショップで買ったUSBケーブル(断線したりしたやつ)を改造したケーブルを持っているのだが、これをターミナルに接続して、モバイルバッテリーに接続して動作確認した。 この時点で、section 2 に関して以下のような事を実施。 最初 10K で動作確認 1秒未満でリレーが「カチッ」と動作</li> 47K に変更。動作する場合もあるが不安定。遅延は2秒ちょっとに伸びる。</li> 33K にしたかったが、手持ちがなかったので、68Kを2本並列に(=34K) 遅延1秒ちょい位で、動作も安定したのでこれにした。</li> </ol> DC5V 入力でリレーが反応する事まで確認。 アンプを接続</h3> PAM8406 を接続して実際に動作するか確認。 この基板、裏のパターンを確認するとすぐに判るのだが、スピーカーの GND は共通 になっている。 PAM8406 を含めたデジタルアンプの多くは BTL 接続で、シングルエンドのアンプとは異なり、GND は L-/R- ( + の逆位相の電圧がかかっている ) であって、GNDではない。短絡してはいけない のだ。 アンプからのマイナスの出力 ( L-/R- ) をこの基板に繋ぐと最悪アンプが壊れるので、絶対に接続していはいけない。 だったらどうする？って話かもだが、 L+/R+ はこの基板の L/R ( 基板裏で短絡してない方 ) に接続する</li> L-/R- はこの基板は通さずにSPに直結する</li> </ul> にすればよい。 上記短絡問題も気を付けつつ PAM8406 を接続してみたのだが、見事に動作しなかったｗ 実はこの基板は遅延リレーだけではなく、DC プロテクトとも書いてある通り ( 後から改めて気づいたw )、スピーカーに流れる DC 検知もして DC漏れしている場合には、リレーを動作させないという保護回路もついているのだ。 お安い回路の割には結構しっかりしていた。 元々基板パターンからして BTL 対応ではない = シングルエンド用であり、この場合にはこの DC プロテクトがあっても問題はないのだが、BTL の場合には + / - ともに電圧がかかっているので、DC プロテクトが反応してしまい、リレーが ON にならないという状態になっていたというのが、動作しなかった原因。 ※ VDD = 5V なら OUT+/OUT- 共に約2.5V(弱)程度の DC が無信号時でもかかっている。 DCプロテクトに繋がっている抵抗を ( section4 ) を変更して PAM8406 の 2.5V が発生しても DC プロテクトが動作しないようにする方法もあるとは思うのだが、これに関しては面倒だった ( そもそもポップノイズ対策の遅延リレーが欲しくて買った ) のもあって、section4 部分の抵抗を外す事で対応した。 DC プロテクトは効かなくなるが、起動時のポップノイズ対策で十分であれば、この改造で要件は満たせる。 最終的には以下のようなアンプになった。 PAM8406</li> Bluetooth(v5)対応 対応基板は安く売ってる</li> 今回のスピーカー保護基板 上記はいずれも USB-C端子から 5V 供給 ( 並列に分岐 )</li> 入力は3.5mmステレオフォン端子からとBTの 2入力対応 切り替えは２回路２接点のトグルで切り替え ( 音声入力の GND は切り替え無しで共通で問題なし )</li> スピーカーも3.5mmフォンジャックで接続タカチの YM-10(YM10-3-7) を使ってコンパクトにしたので、スピーカーターミナルだと厳しかった。あとシルバーをフロントにしたいという YMシリーズの普通の使い方とは違うやり方してるのもある。</li> </ul> 元々、子供が AG03 持ってるのだが、手持ちのパッシブSPがならせなかったので作ったアンプ。 BTは要件ではなかったのだが、単体で動作させることも考えた場合、スマホ等からBT経由でならせる方が汎用性がある。 </blockquote> 写真は以下。基板の固定は 100円ショップなどで手に入る YAMORI GRIP ( 超強力両面ゲルテープ ) を使った。端子部分がケースに触れないようにマスキングテープで保護した上で。 ※ YAMORI GRIP 自体結構厚みがある ( 2mm ) ので、それだけでも問題ない可能性が高いが、金属ケースを使う場合には念のためある程度の対策はしておいた方が良いと思う。 </blockquote> 他のデジタルアンプにも</h2> TA2020 も持っている ( NFJ 基板ベース ) ので、そのうち DC12V のままのバージョンも個人的には作る可能性は高い。 この場合、Section 1, Section 4 のみ対応すれば OK。 これ以外にも PAM8403 等は PAM8406 よりもポップノイズが煩いと言われているので、デジタルアンプで比較的低コストでポップノイズ対策をしたい場合には、この記事の対応が有効かも。 電子工作で改造も伴うので、あくまでも自己責任でお試し下さい。

Zola daisyUI blog

2026-09-25T00:00:00+00:00

はじめに</h2>
Zola + daisyUI 使ったブログテンプレート作ったので、備忘録かねて記事にしてます。
作った理由、セットアップ手順等を記しています。

なぜ作ったか？</h2>
以前から Github pages での個人情報発信は考えていたのだが、ようやく重い腰を上げてアプリを構築した。
mosaos/zola-daisyui-blog</a>
※ 実例は当サイト
当初 React-typescript で簡単なものを実装したり(markdown を表示可能にするところまでは作ってた)、Astro 使う方がとかの AI アドバイスに従って試したりしてたのだが、最終的には以下の技術スタックに落ち着くことに。

Zola
Rust 製の SSG ( 静的サイトジェネレータ )</li>
daisyUI
tailwind CSS 状のコンポーネントライブラリ</li>
Github pages
当初からの要件</li> </ul>
node 止めたのはメンテ地獄にはなりたくないという理由。実務でも React 案件には携わったりしてるのだが、node 系は

関連するパッケージが多い</li>
セキュリティ(脆弱性)対応多い</li>
破壊的変更多い</li> </ul>
破壊的変更は私の得意な言語が Java ( Spring Boot とか)のせいもあるのだが、中身変わってないのにメンテが発生するのは、仕事でやるのはさておき個人の情報発信では面倒。
といった理由で上記の構成になったのだ。 daisyUI も node 必要という人もいるかもだが、CDNで公開されている full.css とかを利用すれば tailwind / daisyUI のビルドプロセスは無しで使える (全部入りにはなる)。最適化がーって話もあるかもだが、メンテ地獄嫌！が最重要な要件なので、CDNのリソース使うのは正義。

機能</h2>
作ったテンプレ。詳細は README.md 参照なのだが、以下のようになっている。
※ ほぼほぼ Zola/daisyUI 等の特性ではある。

レスポンシブデザイン
daisyUIとTailwind CSSによる、モバイルにも対応したシンプルで使いやすいレイアウト。</li>
Markdownベース
Markdown でブログ記事やポートフォリオ作品を簡単に作成可能。記事には目次 ( TOC ) を表示することもできます。</li>
多言語対応
多言語切り替え機能を標準搭載。必要に応じて任意の数の言語に拡張可能。</li>
静的サイト生成 ( SSG )
高速かつ安全で、Node.jsなどのサーバーサイドランタイムを必要としない。</li>
Dev Containers対応
開発環境をすぐに構築でき、環境構築の手間を軽減。</li>
タグ対応
タグ付けにより、コンテンツを整理・分類できる。</li>
画像カルーセル / スライドショー
ポートフォリオ作品などに複数の写真や画像を表示できる、カルーセルを用意。</li> </ul>
開発環境</h2>
以下で確認しています。

Windows 11</li>
WSL2 ( Ubuntu )</li>
docker-ce
Dev Container 使う場合。Desktop ではない。企業でライセンス無い場合も可能。</li>
VS Code</li> </ul>

構築手順</h2>
アプリ部分は Template プロジェクトとして github に登録してあります。お勧めの手順は以下。
尚、ローカルでの動作確認のためにシンボリックリンクを使うので WSL2 上推奨です ( windows の場合 )。
※ Mac は知らんのだ。
各種リポジトリの作成</h3>

mosaos/zola-daisyui-blog</a> にアクセス。</li>
Use this template</code> > Create a new repository</code> をクリック。自分のリポジトリとして作成する ( my-portfolio</code> 等 )。Private</code> でもOK。</li>
コンテンツ用リポジトリを別途作成する。my-portfolio-content</code> 等。Private</code> でよい。これはアプリ部分とコンテンツ部分を分離することで、今後アプリ部分がアップデートした場合に更新しやするするため。面倒な場合は、分離せずに、2 の my-portfolio</code> にコンテンツを含めても問題ない。</li>
github pages 用のリポジトリを作製する (Public</code>)。ドメイン直下で公開する場合にはユーザ名.github.io</code> をリポジトリ名とする。</li> </ol> 一旦ローカルで動作確認</h3> ※コンテンツ用リポジトリを分離していない場合は、シンボリックで付け替える作業は不要 </blockquote> 非 DevContainer の場合</h4> コンテンツをアプリ側の content</code> にシンボリックリンクする。 アプリ側 ( my-portfolio</code> ) 側の content</code> は削除 cd /path/to/my-portfolio rm -rf content </code></pre> コンテンツリポジトリ(my-portfolio-content</code>)をシンボリックリンク ※ 以下は my-portfolio</code> と my-portfolio-content</code> が同じ階層にある場合 ln -s ../my-portfolio-content content </code></pre> DevContainer の場合</h4> シンボリックリンクは機能しないため、mount する。 my-portfolio</code> の content</code> は削除せずに中身を消しておく。 my-portfolio</code> の devcontainer.json</code> に以下 ( mounts</code> 定義 ) を追記する。 "forwardPorts": [ 1111 ], // ホスト側の content 用リポジトリを、コンテナ内の zola 側 content ディレクトリにバインドマウントする "mounts": [ { "source": "${localWorkspaceFolder}/../my-portfolio-content", "target": "${containerWorkspaceFolder}/content", "type": "bind" } ] // "remoteUser": "root" </code></pre> 設定したら Rebuild Container</code> して、DevContainer から content</code> の中身が見えれば(リンクされていれば)成功 動作確認</h4> ローカルで動作確認 cd /path/to/my-portfolio </code></pre> DevContainer の場合は、VS Code に入って DevContainer のターミナルから確認する。 そうでない場合には WSL2(Ubuntu) に導入した zola を使って確認すればOK code . </code></pre> zola serve --interface 0.0.0.0 --port 1111 --base-url / </code></pre> VSCode の場合、Your application running on port 1111 is available. See all forwarded ports</code> というダイアログが表示されるので、Open in Browser</code> をクリックして、サイトが表示されれば OK。非 VS Code の場合、http://localhost:1111/ を開いて確認できれば OK。 .gitignore の調整</h3> 動作が確認できたら、 my-portfolio</code> 側で my-portfolio-content</code> のファイルを多重管理しないように content</code> フォルダ以下は除外しておく ( 以下を追記 )。 content/** </code></pre> my-portfolio</code> で以下も行っておいた方がいいかも。 git rm --cached -r content </code></pre> ここまででローカル側での開発/確認環境が出来たことになる。 必要に応じてコンテンツ追加や、アプリ部分のカスタマイズ等を行うのだ。 PAT(GitHub Personal Access Token)の準備</h3> ここからは GitHub Actions で GitHub Pages にサイトを公開するための設定になる。 ※ ローカル/Dev Container の Zola でSSG 生成して手動でページ公開するといった場合には必要ない。 my-portfolio からは別のプライベートリポジトリ ( my-portfolio-content )と、公開リポジトリ ( ユーザ名.github.io ) へのアクセス権が必要になる。以下の手順で PAT を用意する。 画面右の自分のアイコンから Settings</code> > Developer settings</code> > Personal access tokens</code> から Tokens (classic)</code> を開く </li> Generate new token (classic)</code> をクリック </li> Note に説明 ( portfolio deploy token</code> 等 ) を記載し、Expiration Date を設定する 推奨: セキュリティの観点から 30 days</code> または 60 days</code> ( 定期的な更新が必要 )</li> 個人運用での妥協案: 更新の手間を減らしたい場合は 90 days</code>（期限切れ間近にリマインドメールが届く）</li> </ul> ※ No expiration</code>(無期限) はトークン漏洩時のリスクが高いため非推奨。 </li> Select scopes</code> で以下にチェックを入れる repo</li> </ul> </li> ページ下部の Generate token</code> をクリックし、生成されたトークを控えておく ( ※ 一度閉じると再表示不可 ) </li> </ol> GitHub Secrets へ登録</h3> 発行したトークンを、アプリ側のリポジトリ ( my-portfolio</code> ) に秘密鍵として登録する。 自分の my-portfolio</code> リポジトリのページを開く。</li> Settings</code> > Secrets and variables</code> > Actions</code> に移動する。</li> New repository secret</code> をクリックする。 Name: GH_PAT ( または分かりやすい名前 )</li> Secret: さっきコピーしたPAT の文字列を貼り付ける。</li> </ul> </li> Add secret</code> で保存。</li> </ol> GithHub Actions ワークフローの作成</h3> アプリ側のリポジトリ ( my-portfolio</code> ) のルートに、GitHub Actions 用の設定ファイルを作成する。 ※ 作者の設定になっているので適宜変更すること .github/workflows/deploy.yml</h4> name: Build and Deploy Zola Site on: push: branches: - main # または master ( 自身のメインブランチに合わせる ) jobs: build-and-deploy: runs-on: ubuntu-latest steps: # 1. アプリリポジトリをチェックアウト - name: Checkout my-portfolio uses: actions/checkout@v4 # 2. コンテンツリポジトリ(Private)を content/ フォルダへ直接チェックアウト - name: Checkout my-portfolio-content uses: actions/checkout@v4 with: repository: mosaos/my-portfolio-content # ユーザー名/コンテンツリポジトリ名 token: ${{ secrets.GH_PAT }} path: content # 3. Zola のインストール - name: Setup Zola uses: taiki-e/install-action@v2 with: tool: zola@0.17.2 # バージョンは開発環境に合わせる # 4. Zola でサイトをビルド - name: Build Zola site run: zola build # 5. ビルド成果物（public/）を mosaos.github.io リポジトリへプッシュ - name: Push to mosaos.github.io env: GH_TOKEN: ${{ secrets.GH_PAT }} run: | git config --global user.name "GitHub Actions Bot" git config --global user.email "actions@github.com" # ビルド結果が出力される public ディレクトリに移動 cd public # Gitリポジトリとして初期化してプッシュ git init git checkout -b main git remote add origin https://x-access-token:${{ secrets.GH_PAT }}@github.com/mosaos/mosaos.github.io.git git add -A git commit -m "Deploy from my-portfolio CI/CD at $(date)" git push -f origin main </code></pre> 設定ファイルを作成したら commit / push する。 ※ commit / push 前には config.yml で base_url を自分の github pages の url に変更しておきましょう。 ※ Action が実行されれば OK。この時点で content が登録されていない場合は failure になるが、content 登録後に　Rerun して問題なければ OK。 デプロイ先 ( ユーザ名.github.io ) 側の GitHub Pages 設定</h3> ユーザ名.github.io</code> リポジトリの Settings</code> > Pages</code> を開く。</li> Build and deployment</code> 設定： Source</code> : Deploy from a branch</code> を選択する。</li> Branch</code> : main</code> ( or master</code> )、フォルダは /</code> (root) を選択して Save</code> を押す。</li> </ul> </li> </ol> content 更新をトリガーにする</h2> 上記の設定の場合、my-portfolio への更新 ( main に push ) が Actions のトリガーになります。通常は content が更新された場合にサイトが更新される方が便利でしょう。 この場合以下の設定をアプリ側 ( my-portfolio ) とコンテンツ側 ( my-portfolio-content ) に追加しましょう。 アプリ側 ( my-portfolio ) の設定</h3> アプリ側の .github/workflows/deploy.yml</code> の on:</code> セクションを書き換えて、コンテンツ側からの合図 ( repository_dispatch ) を待ち受けられるようにします。 .github/workflows/deploy.yml</h4> 頭に以下を追記します。 アプリ側のリポジトリに実施したのと同じ方法で、GH_PAT</code> Secrets 登録も行ってください。 name: Build and Deploy Zola Site on: push: branches: - main # または master # 外部 ( コンテンツ側 ) からの待ち受け設定を追記 repository_dispatch: types: [content_updated] jobs: build-and-deploy: runs-on: ubuntu-latest # ( 以下略 ) </code></pre> コンテンツ側 ( my-portfolio-content ) の設定</h3> .github/workflows/deploy.yml</h3> 設定を新規作成します。 name: Trigger App Build on Content Push on: push: branches: - main # 記事（Markdown）を管理するメインブランチに合わせる jobs: trigger_dispatch: runs-on: ubuntu-latest steps: - name: Repository Dispatch uses: peter-evans/repository-dispatch@v3 with: token: ${{ secrets.GH_PAT }} # コンテンツ側にも同じGH_PATをSecretに登録しておく repository: mosaos/my-portfolio # ターゲットとなるアプリ側のリポジトリ event-type: content_updated # アプリ側のtypesで待ち受けている名前と完全一致させる（ハイフンに注意） </code></pre> zola-daisyui-blog の更新に追随する</h2> upstream 登録</h3> Use this template</code> で作成したリポジトリは、Fork とは異なり元のリポジトリとは完全に独立した状態になっています。もし、元のテンプレートリポジトリの更新に追随したいときは以下を実行しておきましょう。 作製したプロジェクトのルートに移動し cd my-portfolio </code></pre> upstream 設定する。 git remote add upstream https://github.com/mosaos/zola-daisyui-blog </code></pre> 登録できたかは以下で確認できます。 git remote -v </code></pre> 元のテンプレートの変更を適用する</h3> まずは変更を取得します。 git fetch upstream </code></pre> 通常のマージだと履歴が無関係と判断されてしまうため --allow-unrelated-histories</code> を付けて merge します。 git merge upstream/main --allow-unrelated-histories </code></pre> 元テンプレートの変更がマージされます。自分が書き換えた部分とテンプレートの更新部分でコンフリクトがあれば、修正します。 修正が完了したらコミットしましょう。 あとは自分のリポジトリに push して完了です。
About Me 2026-09-22T00:00:00+00:00 プロフィール</h2> 名前 : mosaos</li> 職種 : シニアエンジニア / システムアーキテクト / テックリード / 講師</li> 活動領域 : 低レイヤー（物理制御・KVM・インフラ）からWebアプリケーション開発、大規模プロジェクトのファシリテーション・組織的教育までカバー。</li> </ul> 技術サマリー</h2> 【物理制御からDB、大規模PJのファシリテーションまでを完遂するアーキテクト】 圧倒的な問題解決能力とリスク管理: サービス急成長期のDB負荷危機に対し、迅速なPoCを経てオンラインでのテーブルタイプ変更を断行。リリース直前の設計不備に対しても、事業インパクトを優先した現実的な改善ロードマップを提示しプロジェクトを成功に導く。</li> カオスな現場を整理するファシリテーション: ステークホルダー間の調整が難航する会議において、ホワイトボードを用いた可視化により課題の本質を抽出。複雑な調整をシンプルに解決し、専門家からも高い評価を獲得。</li> アーキテクチャ設計とパフォーマンス最適化: 理論に留まらず、Seasar2 + JAX-RS (Jersey) による高パフォーマンスなREST APIの構築や、C++によるビデオフィルタ実装など、低レイヤーからWebまで広範囲をカバー。</li> 実戦型教育のスペシャリスト: アクティブリコール重視の独自カリキュラムにより、累計数百名のエンジニアを現場へ輩出。</li> FinOps & DevOps: AWS CUR可視化によるコスト最適化、および自作KVM基盤上へのDevOps環境（GitLab-CI/Sentry等）の構築。</li> </ul> 主な経歴</h2> 現在 : 都内企業にて、アプリケーション開発およびエンジニアリンググループのマネジメント、社内勉強会・仮想化基盤の啓蒙/主導等に従事。</li> 過去の主な参画領域 : 大手自動車メーカー向け開発・コンサル: 独自フレームワークのセキュリティ分析からの刷新提案、高級車ブランド向けシミュレーター開発の完遂。</li> 自営業 / フリーランス: 大規模な動画配信プラットフォームの更改、大手小売業ECサイトの刷新など、Javaアーキテクトや、DBエンジニアとして各種プロジェクトに参画。</li> 外資系R&D: Windows サーバグループのR&D（日本拠点）、ネットワークコンポーネントや相互運用パッケージのQA・検証を担当。</li> 黎明期からのSI・Webオープン系開発: 汎用機オペレータからC++による端末アプリ開発、大規模なJ2EE/Java案件のテックリード・プロジェクトマネジメントを多数経験。</li> </ul> </li> </ul> テクニカルスキル</h2> 言語: Java (Spring/Seasar2), C#, C++, C, Python, PHP, JavaScript (React), etc.</li> DB: MySQL, PostgreSQL, Oracle, DB2</li> インフラ: AWS, Docker, k8s, KVM, Linux, OpenVPN, GitLab-CI, Sentry, Metabase, etc.</li> </ul>
ベストプラクティス cron

2026-09-22T00:00:00+00:00

cron の一時停止で問題が発生したのを契機に、差分管理等の話が某所で出たので cron のベストプラクティスに関して示す。
※ とりあえず話聞いて思ってた事、思いついた事を書いただけなので、そのうち他の項目も思い出したり「やっぱこれ違ってた」になるかもしれない。
※ 俺の cron 的な Tips なので、適当なカスタマイズやプロジェクト毎の最適化推奨。
※ かつての記事のリライトのため、現状の環境とは異なる部分があります。
開発</h2>
まずは開発 ( cron実装/設定者 ) 寄りのプラクティスから。
/etc/cron.d を使う</h3>
利用している環境でサポートしている事が前提になりますが、可能であれば /etc/cron.d/</code> を利用しましょう。 ※ crontab -e</code> で直接 crontab を編集しない。
具体的には /etc/cron.d/ 下に複数の crontab 設定ファイルを配置します。
ls /etc/cron.d/ system-a system-b </code></pre> system-a の例
# system-a cron jobs SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root 0 * * * * sysauser sysa-task01 30 * * * * sysauser sysa-task02 </code></pre> これにより

crontab 設定を意味のある形でグループ化できる。</li>
個々の設定に適切なパーミッションを付与する事で、他システムの crontab 設定を不要に編集しないようにする事も可能。</li>
cron 用のシェルスクリプト ( 後述 ) と同様にバージョン管理する場合によりよく機能する。</li> </ul>
個々のユーザが利用する cron 設定を許容する ( ユーザが crontab -e</code> で設定を編集する ) のもOKですが、多くの場合、個々のユーザが cron を利用する・しなければならないユースケースは少ないと思われます。
タスクを実行するシェルスクリプトを利用する</h3> 簡単なコマンドやワンライナーで実行可能な処理の場合に、crontab に直接システムやミドルウェアのコマンドを記載する事は可能ですが、組織で管理するタスクを実行する場合には、必ずタスクを実行するシェルスクリプトを作成し、このファイルに処理を実装。crontab にはシェルスクリプトを実行するように指定する方法をお勧めします。こうする事で以下のようなメリットが生まれます。cron 実行時にはユーザがログインした場合とは環境変数の扱いが異なるためにトラブルが発生する事がある。シェルスクリプト化する事で、コマンド実行前に必要な環境変数を設定したり、場合によっては変更する事が容易になる。</li> シェルスクリプト自体をバージョン管理する事で、処理内容の変更履歴をトラッキングしたり、PR/MRプロセスを挟む事で適切なレビューを行うといった事が可能になる。</li> cron で指定したスクリプトから別の ( 環境変数の設定や通知、ログ出力等の ) 共通処理用スクリプトを呼び出してから実処理を呼び出すといった事も容易になる。</li> </ul> スクリプトのコーディングルールを決める</h3> がっちりルール化する必要はないかと思いますが、判りやすいテンプレートを用意するなどして、記載レベルや処理内容をできる範囲で統一した方がよいでしょう。 適度な粒度でコメントを書く</li> 変更される可能性のある値は変数化</li> 共通処理を決めてこれを使う。共通スクリプト化して呼び出す等</li> </ul> バージョン管理する</h3> バージョン管理をする理由としては、問題発生時に元に戻したり、差分を確認したりする事ももちろんですが、これ以外に以下の点も目指す。 CI/CD によるデプロイ現状アプリケーションのデプロイに関しては CI/CD によるデプロイを行っているプロジェクトも増えてきていると思いますが、Linux のスクリプトや cron 設定等もバージョン管理システムで管理し、CI/CD によるデプロイを行うようにすべきです。 The Twelve Factor App</a> で提唱されている内容等にも繋がりますね。 </li> PR/MR によるレビューリリース/変更絡みでインシデントが発生した場合に、 一人で作業した。</li> チェック体制がなかった。機能していなかった。</li> レビューを行っていなかった。ので対策として「これからはちゃんとする」。</li> </ul> といった話を何度も聞いている気がしますが、この手の対策はスローガンだけ掲げてもまたそのうち元に戻る事が多い。常に PR/MR (プルリクエスト/マージリクエスト) を行う形にして、必ずチェックが入るようにシステム/ツールの力を借りる方が改善効果が高いです。 </li> </ul> ※ GitLab でも push 可能な権限を制限できるはず。MR必須の運用にするならば、指定ブランチへの直pushを制限する等 ( スローガンではなく ) ツールで制約を。 多重起動を防ぐ</h3> アプリケーションを実装する場合には、処理言語系 ( Java 等 ) で多重起動を防ぐための仕組みを利用するのも可だが、Linux の標準ツールである flock</code> を使う事で多重起動を防ぐ事が可能。 */5 * * * * appuser flock -n /var/lock/cron-task.lock cron-task </code></pre> 実際の例を以下に示す。 スクリプト</h4> 処理内容を含むスクリプトを作る。 /root/scripts/sleep.sh を以下で作成。 #!/bin/bash INTERVAL=300 sleep $INTERVAL echo "$INTERVAL sec slept" </code></pre> インターバルで指定した秒数スリープした後 echo でメッセージ出力するだけ。 300 秒 ( 5分間 ) ジョブ継続するように指定。 cron 設定</h4> cron 設定は /etc/cron.d/test ファイルを作る。 # put some comment here * * * * * root flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh </code></pre> flock で多重起動されないようにしています。実行は 1 分間隔。 実行結果</h4> /var/log/cron の出力 Feb 8 16:07:01 mosaos-dev CROND[7083]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:08:01 mosaos-dev CROND[7087]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:09:01 mosaos-dev CROND[7089]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:10:01 mosaos-dev CROND[7091]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:11:01 mosaos-dev CROND[7093]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:12:01 mosaos-dev CROND[7082]: (root) CMDOUT (300 sec slept) Feb 8 16:12:01 mosaos-dev CROND[7096]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:13:01 mosaos-dev CROND[7100]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:14:01 mosaos-dev CROND[7102]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:15:01 mosaos-dev CROND[7104]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:16:01 mosaos-dev CROND[7108]: (root) CMD (flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh) Feb 8 16:17:01 mosaos-dev CROND[7095]: (root) CMDOUT (300 sec slept) </code></pre> 1 分間隔で cron ジョブが実行されていますが、実際の処理 ( echo ) は5分間隔になっているのが確認できます。 タイムアウトを使う</h3> タスクの種類によってはタイムアウトを利用するのが有用な場合があります。通常 cron で実行されるジョブは時間制限なしで実行されますが、場合によっては望ましくない場合があります。一定間隔で実行しているジョブの場合に、一定時間で終了しないと重複してジョブ実行される等。 こういった場合 timeout</code> ( /usr/bin/timeout ) を利用する等して、実行時間を制限できないか試してみるとよいでしょう。 */5 * * * * appuser timeout 10s cron-task </code></pre> flock と同様、実際の例を以下に示す。 スクリプト</h4> #!/bin/bash while true do date sleep 1 done </code></pre> 1秒間隔で date</code> 出力 cron 設定</h4> /etc/cron.d/test ファイルを編集。 # put some comment here * * * * * root timeout 10s /root/scripts/loop.sh </code></pre> 10秒でタイムアウト。 実行結果</h4> Feb 8 16:49:01 mosaos-dev CROND[7261]: (root) CMD (timeout 10s /root/scripts/loop.sh) Feb 8 16:49:01 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:01 JST) Feb 8 16:49:02 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:02 JST) Feb 8 16:49:03 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:03 JST) Feb 8 16:49:04 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:04 JST) Feb 8 16:49:05 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:05 JST) Feb 8 16:49:06 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:06 JST) Feb 8 16:49:07 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:07 JST) Feb 8 16:49:08 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:08 JST) Feb 8 16:49:09 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:09 JST) Feb 8 16:49:10 mosaos-dev CROND[7260]: (root) CMDOUT (2022年 2月 8日火曜日 16:49:10 JST) Feb 8 16:50:01 mosaos-dev CROND[7287]: (root) CMD (timeout 10s /root/scripts/loop.sh) Feb 8 16:50:01 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:01 JST) Feb 8 16:50:02 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:02 JST) Feb 8 16:50:03 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:03 JST) Feb 8 16:50:04 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:04 JST) Feb 8 16:50:05 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:05 JST) Feb 8 16:50:06 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:06 JST) Feb 8 16:50:07 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:07 JST) Feb 8 16:50:08 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:08 JST) Feb 8 16:50:09 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:09 JST) Feb 8 16:50:10 mosaos-dev CROND[7286]: (root) CMDOUT (2022年 2月 8日火曜日 16:50:10 JST) </code></pre> 10秒で処理が中断されているのが判る。タスクによっては途中終了するのは大分まずい可能性があるので、使いどころは注意する事。 運用</h2> 運用寄りのプラクティス。 権限を絞る</h3> cron ジョブを実行する場合には実行ユーザ名を適切に指定し権限を制限する。 0 * * * * root cron-task </code></pre> 上記の crontab 設定は root ユーザで実行するように指定していますが、rootで実行された場合、例えば実行ジョブがシステムディレクトリの重要部分を破壊するものであっても、制限を行うのが困難になります。アプリケーション毎に必要最小限の権限を有するユーザを作成し、これらユーザを指定する方がよいでしょう。 0 * * * * appuser cron-task </code></pre> 出力を捨てない</h3> */5 * * * * appuser cron-task >/dev/null 2>&1 </code></pre> /dev/null</code> にリダイレクトしない。ネットのサンプル等を見てそのまま記載した場合に、よく判らずに出力を捨ててしまっている場合があるかもしれません。が、問題が発生した場合の手がかりを捨てる事になるので、特別な理由がない限り出力は捨てないでおきましょう。 その他</h2> インシデント管理では対策は行われず対応したのみでチケットクローズしてる現場も多数見てきたのだが、その手の環境では、不注意でやっちゃいました系は今後も起こり続ける可能性が高いだろう。似たような問題が頻発する場合、その手の問題が発生しにくいプラットフォーム (ジョブ管理ツール) の導入を検討した方がよい。</li> 商用管理ツールは高い... という場合、オープンソースという手もある。DolphinScheduler</a> とか。使ったことないけど、画面イメージ見た感じはいい感じかも。big data distributed workflow scheduling system の謳い文句通りであれば今後暫くは使えそう。</li> 今後、コンテナ化を推進するのであれば k8s の CronJob</a> を利用する等。プラットフォームによって最適な選択肢は変わってくる可能性も考慮すべし。</li> ベストプラクティスがあっても、実装する個々の開発者や運用担当者が実施しなければ意味はない。プロジェクトや担当者レベルで対応するよりは企業全体である程度の方針を示してベストプラクティスは横展開すべき。</li> </ul>
ベストプラクティス GitLab 2026-09-22T00:00:00+00:00 ベストプラクティスシリーズ。 俺の GitLab 的な? ※ かつての記事のリライトのため、現状の GitLab の UI とはズレがある可能性があります。 はじめに</h2> 個人で GitHub 使ってたり、業務で GitLab 使っている中で、 うまくいった事・うまくいかなかった事いずれもあるわけですが、これら経験を踏まえて、 こうすると上手くいく ( かもよ )</li> こうすると失敗する ( かもよ )</li> この機能使うと便利 ( かもよ )</li> </ul> 的な Tips をまとめてみます。 ※ 俺の〇〇的な Tips なので、適当なカスタマイズやプロジェクト毎の最適化推奨。 ※ 職場等では殆ど利用されていないと思われる系機能に関しても記す。活用する事でプロジェクトの質を上げる事が可能 ( かもよ )。 Git</h2> 基本操作は自分で覚えましょう。 GitLab を利用する場合、Git は利用するはず。 ※ Issue管理は使わない場合はありそう ( タスク管理は Redmine だけど、ソース管理は GitLab という管理ツールミックス状態 ) Git の使い方が怪しい場合は、以下のような方法を利用して基本操作はマスターしましょう。 自分で学ぶ / 調べる ( 書籍 / ネット )</li> 個人で github 等を使って慣れる</li> 詳しい人に聞く企業によっては、全くわかってない状況の方に一から教えてくれる人は少ないかもしれない。</li> </ul> 操作に自信がない場合に、実運用しているブランチを適当に触って壊すとか、企業/プロジェクトによっては追放されるかもな事象です。テスト用のリポジトリ用意して練習しましょう。練習もせず本番環境壊したとかなると、無能扱いされても仕方ありません。 GitLab + GitLab Runner 込みで docker-compose で環境構築する事も可能なので、色々弄ってみたい向きには docker で環境構築するのをお勧めします。 ※ 昔 Git も SVN も使い方怪しいって人見た事あるけど、本当に開発者だったのか? ( 経歴詐称じゃないよね? ) と冗談交じりで疑われていた。 権限管理</h2> プロジェクトにメンバーを追加する場合には適切なロールを割り当てるようにしましょう。 ベストプラクティス cron</a> に書いた ※ GitLab でも push 可能な権限を制限できるはず。MR必須の運用にするならば、指定ブランチへの直pushを制限する等 ( スローガンではなく ) ツールで制約を。 </blockquote> といった対応をする場合、 特定ブランチへの merge/push は特定ロール(以上)のみ許可するといった設定を行う必要があります。 ※ プロジェクトの [Settings]＞[Repository]＞[Protected branches] から行える。 しかし、協力会社メンバー含め、全員が Maintainer 権限といった状態だと、上記設定を行っても適切な制限は行えない事になります。 適切な機能制限が行えない点を挙げましたが、そもそもセキュリティ上問題であり、 Maintainer 権限を持つメンバーは社員のみ ( できれば適切な設定が行える一部のメンバー ) 等に制限し、通常の開発者は Developer 権限に設定するのが適切です。 ※ 監査上も不要な権限を意味なく割り当てるのはNG ( なはず ) Redmine 等にも言える事ですが、何でこのメンバーにこのロール割り当ててんの？な権限割り当てザル状態は結構企業でも見かけた 気がします。何となく、便利だからといった理由で権限付与するのはNGでしょう。もしやっちゃってる場合には修正しましょう。 ブランチ戦略</h2> 既に稼働中なプロジェクトに関しては、プロジェクト毎のブランチ戦略があると思います。既に決まった運用方法があり、上手く行っているのであればそれを使いましょう。 一例として過去に採用したブランチ戦略を示します。 ※ gitflowに似てるので使った事がある方であれば理解は容易いと思います。 master</code> ( または main</code> ) リリース用。運用環境にデプロイされる。 master は直接編集しない。 master にマージした場合は tag を付けます。</li> develop</code> 開発のメインブランチ。master から作成。</li> feature</code> 各 issue に対応したブランチ。 develop の最新から作成。ブランチ名は feature/issueNNN</code> ( NNNはissue番号 ) とした。 issue 毎に個別のブランチを作成し、実装完了後は develop にマージされる。 ※ 当初個々人の開発用ブランチを作成する場合に機能単位ではなくメンバー単位で作成という話もあった ( メンバーが以前そういう方法を採っていたとの事 ) が、この場合、( フロントとサーバサイドで開発者が異なる場合等 ) 一つの機能変更が複数ブランチに跨る可能性もありうる事から、この方法は止めた。</li> hotfix</code> master で致命的なバグが発生した場合に利用。 ( 致命的なバグが発生した ) master から作成。ブランチ名は hotfix/issueNNN</code> ( NNNはissue番号 )。バグ改修後、master にマージされる。</li> </ul> マージする際にはMRを作成し、レビュー後にマージする。 ※ プロジェクトのメンバー構成、MRの内容によってはセルフレビューを許可した。 ※ 上記ルールはチケット駆動開発を手法として取り入れている場合 ( 必ず issue を作成しているはずなので ) 機能し易い。チケット駆動でない場合にはどうするか？チケット駆動開発にしてしまえ！( お勧め )。 ※ ちなみに、以前 feature/#NNN</code> 形式でブランチ名を採用した事があったが、ブランチ名に # が含まれると GitLab へのリンクで問題が発生する ( Slack 通知からリンクされない ) ためこの形式は廃止になりました。ブランチ名に #</code> を含めるのはやめた方が良い。 ブランチ作成</h2> 新たに機能を追加したりバグ修正を行う場合にはプロジェクトで策定/採用したブランチ戦略</code> に従ってブランチ作成を行います。 ブランチの作成は GitLab 上でも行えますが、以下の副作用があります。 GitLab 上で New Branch</code> した場合、作成したブランチが Commit/Push されてしまうため CI/CD ( Pipeline ) が実行されてしまう。 gitlab-ci.yml の条件指定で GitLab 上から New Branch</code> されたかどうかを判別する方法があればよいが、現状判別は出来ないっぽいため、New Branch</code> しただけで CI/CD が実行されてしまう。これは以下の点で都合が悪い不要な CI/CD が走る。色々 ( 計算機リソース、時間、リモートリポジトリ上のストレージ等 ) 無駄。</li> 機能追加やバグFIX等が Push された場合のみ CI/CD が走る方が、CI/CD(Pipeline) で問題が発生した場合に、問題を発見しやすい。ブランチ作成の度 Pipeline が走ると Pipeline の確認がきちんとされなくなる可能性がある。</li> </ul> </li> </ul> 上記の点を踏まえ、ブランチ作成に関しては特別な理由がない限り以下の手順で行うのをお勧めします。 作成元のブランチからローカルでブランチを作成する。</li> 作成したローカルブランチを利用して何らかの変更 ( 機能追加やバグ修正 ) を行い、ローカルでビルド、動作確認を行う。</li> ローカルで Commit する。</li> リモート ( GitLab ) に Push する。新規に作成したブランチに関しては、この時点で初めてリモートにブランチ作成され、CI/CD が実行される。</li> </ol> 上記手順を採用する利点は以下。 実際の変更 ( ローカル Commit ) が反映 ( Push ) されるまでは、リモートにブランチが生成されない。ブランチ作成したけど、結局は Commit/Push されない場合もあり得るが、この場合に GitLab リソースが無駄にならない。</li> 余計なCI/CDが走らない。 GitLab で New Branch</code> した場合、上述の通り CI/CD が走るが、これはブランチ生成元のブランチ( develop 等 ) の最終コミットの状態を再度 CI/CD している事になる。既に CI/CD 確認済みの Commit/Push に対し CI/CD を再実行するのは無駄である。</li> Pipelineの履歴が汚れない。上と関連するが、無駄な Pipeline が走ると Pipeline の履歴に本来不要な実行履歴が残る。CI/CD で何らかの問題が発生して、過去履歴を調査する必要が発生した場合に、この手の履歴が多いと調査コストが増える。</li> </ul> GitLab上から New Branch せずとも、VSCode 等の開発環境でブランチ作成は行える。上記手順でブランチ作成を行うようにしましょう。 ※ 殆どのメンバーは上記手順でブランチ作成していたが、一部メンバーがGitLab上で New Branch した際に Pipeline 実行される状態が発生。なんだ?この Pipeline となったため、上記内容でかつて文書化/展開した。 ※ 「うちのプロジェクトでは CI 使ってないからいいや」と言う方もいるかもしれないが、今後 CI を導入する可能性は常にある。一度慣れてしまった方法を直すのは ( メンバーにもよるが ) コストが高い場合がある。より問題が少ない方法を採用する方がよいと思う。 コミット</h2> コミットする場合にはコミットコメントを適切に書きましょう。 GitLab でチケット駆動開発を行っている場合、コミットは先に起票しているチケット ( issue ) に対応する作業なので、コミットコメントには issue id を記載するようにします。これによって issue とコミットが自動的に関連付けされます ( 相互リンクが張られる )。 issue idを記載する場合 #nnn</code> 形式 ( nnn は issue id (10進数値) ) で記載する。場所はコミットコメントの最初に書くのが判りやすく、書き忘れにくい。 ※ # nnn</code> と # と nnn の間にスペースを入れてしまってリンクが張られていないのも見た事があるので、間にスペースは入れないように。 ※ チケット自体は Redmine で管理している場合にも、Redmine のリポジトリ機能を利用し、Git リポジトリと連携する事でチケットとの連携を行う事も可能である ( 設定は別途必要 ) 。 マージリクエスト</h2> マージを行う場合には必ずマージリクエスト ( MR ) を作成する。 ( MR 無しでのマージは行わない ) GitLab のメニューから Merge requests</code> をクリックする。</li> MR一覧画面が表示されるので New merge request</code> ボタンをクリックする。</li> Source / Target の二つのブランチ入力欄が表示されるので、それぞれのブランチを設定します。通常の機能開発を行っている場合には、以下のようになります。(hotfixの場合やmasterへのマージの場合にはこれとは異なります。不安な場合は識者に相談して下さい)</li> </ol> Source branch にマージするブランチ (feature/issueNNN)</li> Target branch にマージ先のブランチ (develop)</li> </ul> Compare branches and continue</code> をクリックする。</li> New merge request 画面に遷移するので、先ずは変更内容を確認します。画面を下にスクロールすると、Commits</code>, Pipelines</code>, Changes</code> タブが表示されているので、以下が正しいかを確認して下さい。もし問題があった場合には一旦MR作成は止め、ブランチ作成手順やファイル編集に問題がないか解決してから再度MRを作成するようにしましょう。</li> </ol> Commits MRに含まれるコミット内容。自分が行おうとしているMRと異なる内容のコミットが含まれる場合は何か問題があると思ってください。</li> Changes MR前後のファイル差分が含まれます。差分(変更)内容が正しいかを確認して下さい。自分が行っていない変更や、誤った変更内容が含まれた場合には何か問題があると思ってください。</li> </ul> Commits</code>, Changes</code> に問題が無い場合には、以下MR内容を適宜設定して下さい。</li> </ol> Title MR のタイトルを適宜設定して下さい。</li> Description MR に含まれる変更の概要を書いておくと良いでしょう。</li> Reviewer 誰かにMRをレビューして欲しい場合にはそのメンバーをレビュアーに設定して下さい。GitLabで設定しただけだと相手が気づかない場合もあるため、Slackなどでレビュー願いも通知するのがお勧めです。</li> </ul> Create merge request</code> をクリックします。</li> レビューを依頼されたメンバーはMRの内容に問題がないか確認し、必要であればMRにコメントして下さい。</li> MR作成者はレビュアーのコメントに対して説明やコード修正等を行い問題を解消して下さい。</li> 6 -> 7 のプロセスを繰り返し問題がなくなったら、レビュワーは MR の Approve</code> ボタンをクリックします。</li> MR作成者 ( あるいは、MRをアサインされたメンバー ) は Approved された事を確認して、Merge</code> ボタンをクリックします。デフォルトでは Delete source branch</code> にチェックが入っています。マージ後もソースブランチ(feature/issueNNN等)を削除したくない ( その後もそのブランチで作業する ) 場合にはチェックを外してから Merge</code> ボタンを押しましょう。</li> </ol> 企業などでも時々発生する 一人で作業した。</li> チェック体制がなかった。機能していなかった。</li> レビューを行っていなかった。</li> </ul> といった問題を防止するためにも有効です。 issue作成</h2> issue を作成する場合、適切な issue を作成する。 ベストプラクティス Redmine</a> にも似たような事を書いたのですが、以下のような点に気をつけるとよいでしょう。 適切な粒度で作成</li> 適切なタイトルを付ける</li> 必要十分な説明 ( 概要 ) もきちんと書く</li> 複数のタスクを書かない</li> 終了条件が明確になるようにする</li> 担当を割り振る</li> 期間を設定する ( 仮の期間でも良い )</li> バグの場合、再現手順、環境(利用ブラウザ等)、バージョン等必要な情報を記載する ※ 且て某外資系で働いてた時に、BTS(bug tracking system) にこの手の情報書かずに登録して「クソなissue書いてんじゃねー。とっとと書き直せ」って返されてるの見た事あるw。</li> </ul> ここからはあまり使われていない系 ラベル</h2> issue にはラベルを付ける事ができる。ラベルは Project 単位で設定可能。利用する事で issue の視認性が向上する。 ※ board (カンバン。後述) やissue 一覧表示時に特に有用。 ※ 背景色も個別設定可能なので、適切に設定して運用していれば、ラベル色からどの系統の情報かも判るようになってくる。 プロジェクトの左メニュー一番上のアイコン[Project information]＞[Labels] から設定できる。 私は以下のようなラベルを設定している。 カンバン用</h3> Doing</code> 実行中。色は #5CB85C</li> To Do</code> 実行予定。色は #F0AD4E</li> </ul> Close 系</h3> Closed issue の分類に利用。色は #808080 Close: Fixed</code> 修正/対応した</li> Close: Wontfix</code> 対応しない</li> Close: Duplicate</code> 重複している</li> Close: Invalid</code> 誤っている</li> Close: Postponed</code> 延期</li> </ul> Priority 系</h3> 優先度 Priority: Critical</code></li> Priority: High</code></li> Priority: Middle</code></li> Priority: Low</code></li> </ul> 優先度系は順位付け可能なのでラベル背景色をグラデーションになるように設定している。 Critical から順に #ff0000, #ff4400, #ff8800, #ffbb00 Type 系</h3> issue 分類。色は #6699dd Type: Bug</code> バグ</li> Type: Documentation</code> 文書/資料作成</li> Type: Feature</code> 機能追加/拡張</li> Type: Refactoring</code> リファクタリング</li> Type: Review</code> レビュー</li> Type: Test</code></li> </ul> issue 一覧やカンバンがカラフルになるだけで、何となく気分が上がる ( ※個人の感想です ) し、視認性が高まるという点においてデメリットは少ないと思われる。 尚、ラベル設定した際に、issue には必ずラベルを付ける必要があると受け取ったメンバーがいましたが、そうではありません。 ラベルの種類によっては付与を必須にしてもよいものもあるかとは思いますが、優先度等 issue 作成者が直ぐに設定可能とは言えないでしょう。一旦ラベルが付与されてしまう＝既に設定済み・設定したラベルで問題が無いと受け取られる可能性もあるため、確実に設定可能なもの以外については付与せずに打合せの中等で設定する方がよいと思います。 ※ Scoped labels</a> という機能があって、これが利用できればと考えていたが、非PREMIUM版では利用できなかった。この機能はラベル名に ::</code> を入れる事で key::value 形式のラベルを設定できるとの事。Priority や Severity といったラベル付けをする場合にはこの形式が使えた方が便利。 Reference</h3> Labels</a></li> </ul> マイルストーン</h2> Issues</code> > Milestones</code> から設定/利用できます。 私は仕事での実プロジェクトでもマイルストーンを利用して、各リリースで行う内容(予定)を記載していますが、私の周りではマイルストーンを設定しているプロジェクトは少ないように思われます。請負開発で作ったら終わりといった場合でない限り、現在、あるいは、これから行う(次リリース)までの開発で何を行うか？ ( 主目的や主な追加機能 ) を記しておくとプロジェクトの見通しがよくなります。個々の issue までマイルストーンに記載する必要はありませんが、issue 自体にマイルストーンが設定可能なので、 その issue がどのマイルストーンで実施されたのか？</li> あるリリース ( Milestone ) で対応された issue には何があるのか？</li> </ul> といった振り返りに利用する事も可能ですし、 issue としては上がっているが、そのタスクは現マイルストーンでは行わない事を示す (要望としては把握、ただし、実装未定扱いにする) 用途にも利用できます。</li> </ul> Reference</h3> Milestones</a></li> </ul> カンバン</h2> Issues</code> > Boards</code> から利用できます。 GitLab 上では Boards となっていますが、カンバンの方が馴染みが深い方が多いのではないかと思われます。 GitLab上ではデフォルトでは以下の状態が用意されています。 Open</code> issue が作成されたときの状態</li> Closed</code> 作業が完了したら Closed</code> に移動</li> 上記以外にカンバン上の状態を表すラベルを設定可能。</li> </ul> 個人的には Redmine でガントチャートベースでタスクを回す事が多かったのですが、幾つかのプロジェクトでは取引先のマネージャの希望等からカンバンベースでタスク管理をしたこともあります ( Redmine の場合、Agileプラグインを利用 )。カンバン上で関係者でタスクを確認し、それぞれのタスクの状態を変更してゆくという事を定期的に行っていました。 タスクの大まかな状態を全員で確認できる。</li> 重要なタスクは順番を入れ替える(上に持ってくる)といったルールで運用する事で、タスクの重要度/優先度も可視化できる</li> 担当者も表示されているので、誰がどの程度のタスクを抱えているかも把握しやすい。</li> </ul> プロジェクトの形態や規模、参加メンバーの属性等によって向き/不向きもあるため、必ず利用すべきといったものではありませんが、利用した事がないのであれば試してみる価値はあるでしょう。 「小規模でガントチャート作るまでは...」といった場合</li> アジャイル的な開発手法を採用している場合</li> </ul> に親和性が高いと思います。 Reference</h3> Issue boards</a></li> </ul> 参考</h3> GitLabイシューボードでkanbanやスクラムを試してみる</a></li> </ul> 時間管理</h2> Time tracking</code> と Due dates</code> を利用する事でタスクの時間管理やスケジュール管理をする事が可能です。 プロジェクトを進めるうえで各タスク ( issue ) の時間管理は重要です。タイムトラッキングするまでもなく、順調に進んでいるプロジェクトの場合にはガチガチな時間管理をする必要はないと個人的には思ってますが、 進捗が芳しくない</li> タスクにどの程度の工数がかかるか把握できていない</li> </ul> といった状況が続いている場合、先ずは見える化する事からはじめるのが良いでしょう。可視化されていない問題は放置される/改善されない事が殆どなので、可視化するのがファーストステップです。 GitLab の Time tracking</code> と Due dates</code> を利用する事でタスクの時間管理やスケジュール管理をする事が可能です。 各 issue について、 どの程度かかりそうか見積もり /estimate</code></li> 実際にかかった工数 /spend</code></li> いつまでに出来そうか Due date</code></li> </ul> を記録する事で見える化が可能です。 見積もり</h3> issue のコメントで /estimate 1w 2d 5h</code> といった風に入力する事で見積もり工数を入力できます。 コマンドを途中まで入力するとヒントが表示されるので参考にしましょう。</li> 1w == 7d ではなく 1w = 5d なのでその点は注意しましょう。</li> 当然 1d = 24h でもありませんが、これに関して間違う方はいないと思われ</li> </ul> 見積もりを取り消す場合は remove_estimate</code> で。 変更する場合には /estimate xxx</code> を再入力します。以前の値に加算されるのではなく、上書きされるようなのでこちらも注意しましょう。 実工数</h3> issue コメントで /spend xxx</code> で入力します。時間のフォーマットは estimate</code> と同じです。 ※ /spend に関しては入力した値は加算されます ( /estimate とは異なるようです )。 estimate と spend 両方入力すると、issue 右側の Time tracking</code> 欄に進捗がバー表示されるようになります。 期限</h3> 期限は issue の右側にある Due date 欄で入力します。 issue コメントで /due xxx</code> で設定する事も可能ですが、xxx 部分の書式は in 2 days</code> とか this Friday</code>, December 31st</code> とか例に出てきて日本人的には馴染まない可能性が高いので、Due date 欄でカレンダー設定するのがお勧めです。 期限を過ぎている issue は表示色が変わって表示されたり、To-Do List</code> (GitLab右上にあるアイコンからアクセスできます) での表記が変わります。 Reference</h3> Time tracking</a></li> Due dates</a></li> </ul> ガントチャート</h3> Premium、Ultimate ならば Roadmap</a> 機能でできるらしい。 https://github.com/lamact/react-issue-ganttchart を利用して Due date を元にしたガントチャート表示は行った事があります。CE などでガントチャートを利用してみたい場合には試してみても良いでしょう。 ※ GitLab 自体の機能ではありません。 MRのDraft機能(旧WIP)</h2> MRの Title 入力欄の下に Start the title with Draft: to prevent a merge request that is a work in progress from being merged before it's ready.</code> という記載があり、Start the title with Draft:</code> リンクをクリックすると、この MR がドラフト状態だと示す事ができます。これは且て WIP (Work In Progress) と呼ばれていた機能で、Draft状態で作成された MR はマージボタンが押せない状態で作成されます。 作業途中でまだ完成していないがレビューやコメントが欲しいといった(ドラフト)状態にある場合に、MR の Draft 機能を利用するとよいでしょう。 GitLab上でドキュメントの管理をしている場合で、メンバーのコメントやチェックが欲しいといった場合にも活用できると思います。 Draft 状態で作成した MR もレビュー内容を反映した後に Mark as ready</code> ボタンで非 Draft 状態に変更する事も可能です。( 再度 Draft 状態に戻す事も可能 ) Reference</h3> Draft merge requests</a></li> </ul> それでも発生した問題</h2> 上記のようなルールを策定しても、問題が発生する事はあります。具体的例を示します。 何する issue ?</h3> タイトルだけや、概要説明が不十分な issue が作られ、何するの?状態になった事がありました。 流れを書くと、以下のような感じ メンバーＢ：「〇〇に関して××の問題があるので、対応すべき」</li> メンバーＡ：「対応します」</li> メンバーＢ：「issue 書いてください」</li> メンバーＡ：「了解」</li> メンバーＡ：issue 作成 (タイトルのみ) タイトル内容も〇〇を決める</code> 等、何の? となるようなタイトル。</li> </ol> その後、暫く issue 対応はされずに放置される ( 他に優先するタスクがある等の理由 )。 メンバーＡ：「決める必要のあるものがない」といった理由で issue クローズ。</li> メンバーＢ：問題は解決していない旨コメント。</li> メンバーＡ：もう覚えていない旨告白。</li> </ol> issue に必要十分な内容が記載されていれば、避けられる問題です。 ※ 同様の問題は繰り返し引き起こされる場合があります ( 経験的に )。 ※ 繰り返し発生する場合には、メンバー自身に対応策を策定してもらうのがベストですが、無理な場合には issueのテンプレートを用意</a> しましょう。 ブランチ名が命名規約に従っていない</h3> 命名ルールに従いましょう。新規ブランチを GitLab に push する際には、 ブランチ名が適切か？</li> 既存のブランチがどうなっているのか？</li> </ul> といった点を確認するのをお勧めします。 ブランチの作成手順に問題 ( 多分 )</h3> かつて、MR に既にマージ済みの変更が含まれていた問題がありました。 feature ブランチ作成時に最新の develop からではなく、( おそらく ) ローカルの develop を最新状態にせずにブランチを作成したのではないかと思われます。仮に誤ってそのまま MR に進んだとしても、MR 作成前に差分を確認していれば ( GitLab 上で確認できる )、自分が当該の feature ブランチで行っていない変更が含まれるために気づくはずです。この問題が発生した理由としては以下の二つが含まれます。 ブランチ作成ルールがダメ</li> MR時にレビューしていないレビュアーがいない場合でも自分でMRに含まれる差分が適切かどうかの確認は必要です。セルフレビューの場合、自分自身できちんとチェックしましょう。</li> </ul> まとめ</h2> 権限まわりザルな設定するのはホント止めた方がよいと思う。 Oracle ユーザ管理ベストプラクティス 2026-09-22T00:00:00+00:00 Oracle ユーザ管理ベストプラクティス</h1> 俺的ベストプラクティスシリーズw 開発環境等、個人で利用するものに関してはここでは触れません。特にプロダクション環境 ( 及び、複数人で利用するステージング環境 ) におけるベストプラクティス。 ※ Oracle マスターではないので、誤った情報を含んでいる可能性があるかも。ご了承下さい。 ※ プロダクション環境の DB にアクセスユーザをどのように管理すればよいかに関して、ベストプラクティス的なものを書きなぐってます。 ※ DB に限らず、アプリケーションや OS の権限管理にも通じるものもあると思う。 ※ 誰かがやらかしたときに勢いで書いたネタ... ※ かつての記事のリライトのため、現状の Oracle の仕様・UI とはズレがある可能性があります。 用語</h2> 用語をいくつか定義しておきます。 DBA Database Administrator の略。データベース管理者。データベースに対してなんでもできる(すべての権限を有する)人/アカウント</li> デフォルトユーザ [第21回] デフォルトで最初から作成されているユーザー</a></li> プロダクション環境本番/運用環境のこと</li> ステージング環境検証等を行うための環境。本番適用前の事前検証やテストに利用される。個々の開発者の開発環境とは異なり複数人で利用される。</li> </ul> ベストプラクティス</h2> ユーザではなくロールに権限を付与する</h3> オラクルにはロール(ROLE) を扱う仕組みがあるので、個別ユーザに権限を与えるのではなく ROLE に権限を割当て、個々のユーザはロールに属するよう設定を行います。 参考 : ロールの確認／作成／付与／変更／取り消し／削除</a> ユーザには必要最小限のアクセス権を与える。</h3> 管理を緩めにしたい場合、ユーザに多くの権限を割り振りたくなりますが、これによってセキュリティリスクをもたらす可能性があります。重要なシステムの場合には、そのユーザが作業を行う上で必要最小限の権限のみ与えるようにしましょう。 監査を行う</h3> オラクルにはログインの試行や作業内容を監査するための仕組みが存在します。監査が無効な場合には、必要十分な監査が行えるように監査を有効にしましょう。 デフォルトユーザは可能であればロックする。</h3> [第21回] デフォルトで最初から作成されているユーザー</a> は攻撃者にとっては最も狙いやすいアカウントであるため、可能であればロックするのが望ましいです。ロックできないアカウントに関しては、十分な強度のパスワードを設定しましょう。 デフォルトユーザをDBAにしない</h3> SYS/SYSTEM等のデフォルトユーザをDBAユーザにする事は簡単ですが、DBA操作を行う個人に対してDBAユーザを作成しましょう。これは以下の理由からです。 監査共有の特権アカウントを利用している場合、どの利用者がDBA作業を行ったのか監査追跡を行うのは面倒です。個別のユーザを用意しておけば監査はより簡単に行えます。</li> パスワード管理 DBAユーザでも自分以外のパスワードは知らない状態にすることで、離職時のパスワード管理が簡単になります。セキュリティや監査の面でも有効です。</li> </ul> DBAロールと開発者ロールを分ける</h3> アプリケーションの開発中、特に開発環境においてはDBAと開発者は同一である事が多いですが、プロダクション環境ではDBAと開発者は別の事が殆どです。これら二つの役割(ジョブ)に対しては異なるロールを作成し、別々に権限を割り当てるようにしましょう。 アプリケーション/DBA用のユーザは匿名性を排除する</h3> アプリケーションが利用するユーザは、どうしても代表ユーザになってしまうことがあります。アプリケーション用の代表ユーザは強力な権限を持っており、アカウント情報が流出してしまった場合でもパスワードを変更することは難しい事も多いです。しかし、運用担当者が離職した後でも、昔使っていたパスワードでシステムにアクセスできてしまうかもしれません。データベースに直接アクセスするアプリケーションおよびデータベースの管理運用担当者用には、匿名性を排除して厳密なアクセス制御を行うために、個別のアカウントを作成するのが望ましいです。 ロールを入れ子にする</h3> Oracle のロールはネストする事が可能です。個人的に設定した事はないのですが、以下のような設定を行っているのを見たことがあります。 開発者用の DEVELOPER</code> ロール</li> DBメンテナンス者用の MAINTAINER</code> ロール</li> DEVELOPER</code> と MAINTAINER</code> の両方の権限を有する MANAGER</code> ロール</li> </ul> DEVELOPER の権限が更新されると、MANAGERのロールも更新されます。複数のタスクを行うジョブ(利用者)が存在する場合には、ロールをネストする事で管理を柔軟にし、管理コストを減らせる可能性があります。 CONNECT/RESOURCE ロールは利用しない。</h3> CONNECTロール等の一部ロールは Oracle に組み込まれていますが、これらロールは利用しないようにしましょう。 10g R2 から「最低限の権限」原則により CONNECT および RESOURCE ロールは非推奨になっています。 Oracle CONNECTおよびRESOURCEロールのまとめ</a> ※ バージョンによって権限内容などが異なるようであるため、理解せずに利用するのは危険。 PUBLIC に注意する</h3> PUBLIC に権限を付与すると、誰でもその権限を使用できるようになります。 [第22回] PUBLICに注意</a> ユースケースを元にロールを決める</h3> 運用を踏まえて以下を検討しましょう。可能な範囲でよいので、アクセスマトリクスを作成する等して、権限をまとめ、可視化しましょう。 利用者 DBを利用するユーザは誰か。どんな利用者がいるか。</li> 権限利用者の種類(アクター)毎にどんな権限が必要か。</li> </ul> まとめ</h2> 開発段階にある場合など全て決めるのが難しい場合もあると思いますが、できる範囲でユーザ/ロールを策定しましょう。新たなアプリケーションの追加や新機能の追加といったタイミング等、適当なインターバルで見直しを行いましょう。 問題発生時も見直すためのよい機会です。 参考</h2> [第21回] デフォルトで最初から作成されているユーザー</a></li> [第22回] PUBLICに注意</a></li> Oracle CONNECTおよびRESOURCEロールのまとめ</a></li> ロールの確認／作成／付与／変更／取り消し／削除</a></li> 安全なデータベース運用のキモ、ユーザーのアクセス制御をどう設定すべきか</a></li> </ul> ベストプラクティス Redmine 2026-09-22T00:00:00+00:00 はじめに</h2> ここではRedmineマニュアル的な使い方の話ではなく、 Redmine ( やそれに類するプロジェクト管理ツール ) を利用する上で、 気を付けるとよい点</li> こういう使い方は止めた方がよい点 (バッドノウハウ)</li> </ul> に関して書いてみます。 ※ Redmine Japan で聞いた事とかもまとめています。 ※ Redmine 以外のプロジェクト管理ツールを利用する場合にも有効 ( だと思う )。 Redmineとは</h2> もともとはIT開発者向けとして開始されましたが、現在では様々な分野や仕事で利用されているプロジェクト管理ツール です。 プロジェクト管理ツールって何？と聞かれた場合には、「やるべき事を付箋に書いて、できたらはがす」 事を ITの力を借りて、</li> よりシステマチックに</li> </ul> 行うものと説明しています ( 私は )。 付箋＝Redmineのチケットなので、 やる事をチケットに書いて、</li> 出来たら消す。</li> </ol> という事になります。 チケットを消す</h3> という事でRedmineを使う目的を1つ上げるとすると 「チケットを ( 書いて ) 消すこと」 になります。 ※ ゲーミフィケーション的に「チケットを消すのが快感」になるようできると定着しやすい。 自分のチケットを消す</li> 他メンバーのチケットも消す</li> 記録を残す</li> </ul> 併せて、チケット消化のために行ったアクションをきちんと記録する。 消すために</h4> 消せないチケットが増えると、モチベーションも上がりませんし、ツールの利用も促進されません。消しやすいチケットにするために、以下のような事に気を付けましょう。 消しやすい粒度でチケットを切るあまりに範囲が広い ( 粒度が大きい ) チケットは消せない。 → 子チケットに分割する ( 数時間～数日単位を目安に消化できる粒度で作る )。</li> 複数のタスクを書かない記録 ( コメント ) を残す場合でも、どのタスクに対する作業か判りづらくなる。 → 上と同様ですが、適切な粒度の子チケットに分割する</li> 終了条件が明確になるようなチケットを切る「運用改善」のようなチケットだと、何が行われたら終了できるか判らない。 →「〇〇を××する」といった実際に行う必要があるアクション、及び、終了条件が判るようなチケットにする。</li> </ul> 見える化</h3> 記録を残す事で、見える化が可能になります。可視化は重要。何を可視化したいのか/すべきかはしっかり意識しましょう？ここがぶれると余計な情報が増えたり、可視化したいものが欠落したりします。 ここはプロジェクト次第で、「これ！」というものを提示するのは難しいので、例を示します。 以下、開発プロジェクトの場合の例 やる ( べき ) 事チケットに書く ( 粒度に気を付ける )</li> 担当を割り振る ( 未決ならばプロジェクト管理者等割り当てを実施する人に )</li> 期間を設定する ( 仮の期間でも良い )</li> 適切なタイトルを付ける</li> 必要十分な説明 ( 概要 ) もきちんと書く</li> </ul> </li> スケジュールチケットに期間、進捗率を記録する事でガントチャート化</li> タスクの状況対応内容はきちんとコメントに書く。ステータスや担当者も適宜変更する。</li> </ul> </li> </ul> 運用する上で気を付ける事</h2> 設定はあまり細かく分けない Redmineを運用する上では、各種設定を細分化したくなります。しかし、細分化するほど設定・運用・メンテナンスのコストは増えます。可能な限り細分化しない事をお勧めします。</li> 組織構造をそのまま反映するのは基本止める実際の部署や役職を元に最初にデータを構造化するのは結構ありがちかと思われますが、これをやると大抵失敗するか、管理が辛くなります。</li> </ul> プロジェクト管理ツールはプロジェクト内の組織構造や役職の構造を管理するためのツールではありません。あくまでタスクを捌くためのものです。目的のために必要最小限で効率のよいトラッカー、ステータス、ロール、プロジェクトを定義する事をお勧めします。最初はミニマムで始め、必要に応じて変更/改善しましょう。 以下具体的なバッドノウハウ ( 例 ) を記載していきます。 トラッカーを分けすぎない</h3> トラッカーってチケットの区分だから、業務種別毎にトラッカーを分けて作ろう。 → 「業務/部署ごとに分けて作ろう！」 ってのはありがち。 ※ Redmineのトラッカー＝帳票 の意味合い。( 入力項目があって、承認フローがある )。 でも、 トラッカーをたくさん作ったけど、実はワークフローが一緒って事が多い。 入力項目もワークフローも同じならトラッカーは同じものが使える可能性が高い。</li> 設定が多いほど、管理コストやメンテナンスコストが上がる。</li> 後で整理しようとしたときに辛くなる。</li> </ul> 入力項目多すぎ</h3> トラッカー = 帳票と言いましたが、カスタムフィールド追加しまくって何入力すればいいか判らない。って事にもなりがち。 結局入力してないフィールドがある</li> 形骸化していて、利活用されていないフィールドがある</li> </ul> 後々、分析や集計に利用するのでなければ、普通にチケットの説明欄に記載するので十分な事が多い。 入力はしてほしい項目がある ( 分析まではしない ) のであれば、Issue Templates プラグイン使いましょう。 → トラッカーの乱立も防止できます。 ※ 実際に入力項目100個とかあるらしい... 地獄 ※ 担当者以外に、対応者とかあるトラッカーあるけど、違いって何？ ステータスは必要最小限に</h3> 必要以上に細かくすると判り難い。 → どのステータスを選べばよいか、プロジェクト参加したばかりの人が把握できるのがよい状態。 業務フロー整理できていますか？実際の業務では存在するステータスでもシステム上では不要な場合もあります。必要かどうか微妙なステータスを作成するのは止めましょう。どうしても必要になった時点で追加すれば済むことです。</li> 担当者が割り振れないステータス本当に必要ですか？ → チケットが消化されなくなる可能性が高くなります。</li> 同じワークフローに位置するステータスが複数ある ( 部署が違う場合に別で作られている等 ) なら纏めましょう。</li> </ul> ※ 実際にステータスが30個とか...あるらしいワークフロー把握/理解できるのか？ ※ Redmineでもプラグイン追加によってカンバン利用できますが、ステータス30個のカンバンとかカオス... ロールも細分化するのは止めよう</h3> いろんな人が見れるのは良くない。ロールで詳細に権限を分けよう。 → 役職毎とかにロール作ってるとこ見たことある。。。 PMとかPMOとかPLとかRedmineで何ができるロールだっけ？ → 承認者、レビュワー、オブザーバー等役割が明確なロールの方が良い。 ※ PM だからこの権限、PL だからこの権限、と役職に合わせてロールを作る必要はありません。 ワークフローは？</h3> ワークフローはロール×トラッカーの数だけある。 多くなると管理が大変。 ワークフローが同じものは、できるだけ同じトラッカーで扱えるようにする。 ( 承認不要 ) タスク</li> 顧客承認タスク</li> 上長承認タスク</li> </ul> 等のようにワークフローが同じトラッカーはまとめてしまって、部署を跨いだ場合でも同じトラッカーが使えるようにする方が判りやすい。 プロジェクトも不用意に細分化しない</h3> 「案件単位でプロジェクト」とかありがちだけど。。。 「バージョン」利用で足りるのであれば、バージョンを活用しましょう。 Redmineではソースコードとの連携も行いやすくなっています。 → 適切なプラグインを併用する事で Redmineサーバ上で Subversion/Git リポジトリサーバ構成も可能です。 → 製品/サービスとプロジェクトを一対一で紐づけるのがお勧め。</li> </ul> 「〇〇サービス××改善」のようなプロジェクトがある場合には、「〇〇サービス」プロジェクトで、「××改善」バージョンを作成する事で、任意の製品/サービスのロードマップ毎に分割可能になります。 GitLabでのMilestoneも同様です。</li> </ul> 組織階層で構造化するのは悪手</h3> ありがちです。 が、複数の部署が連携して行わなければいけないプロジェクトの場合は？ → おすすめは案件単位但し、フェーズが分かれる場合には不用意にプロジェクト分割せずに、バージョン利用解決できないか検討しましょう。 バージョンの使い方としてどうよ？</h3> 基本、バージョンは期間を区切るものとして使うようにしています。 プロジェクトを期間以外の軸で分割するのに使っている場合もあるようですが、 期間で分割したくなった場合に、適切に分割できなくなるので、その手の要件が絶対に発生しないプロジェクト以外で採用するのは止めましょう。 メンバー追加しすぎ</h3> 考えるの面倒だったの？メンバー多すぎだろ？ 基本的には、当該プロジェクトに実際に関わる方のみメンバー追加するようにしましょう。 閲覧だけさせたい？ → 公開プロジェクトでよいのであれば、それで足りる。 終わりに</h2> 特に運用開始時、トラッカーのステータス、ロールの追加を行う際に、「項目追加したぞ！うちの会社に併せて構造化されている＆ワークフローも反映されてて完璧。スゲー！」とか思ってしまう場合もあるかもしれませんが、 単に業務分析や抽象化が出来ていないだけかもしれません。より少ない設定でうまく回せるような方法を考えましょう。 設定が細かいことと、業務を適切に抽象化できていることは別です。 コーディングルール (Java) 2026-09-22T00:00:00+00:00 Java 開発する中で個人的にまとめたコーディングルール。 ※ 企業でのプロダクト開発などでの経験も踏まえてはいる。 はじめに</h2> 良いコードかどうかの一つの指標として「他人が読んでもわかりやすいかどうか？」というものがある。コードがわかりやすいかどうかは、ロジックの判り易さはもちろん、フォーマットやAPIの常識的な利用方法など、様々な要素から決定される。複数人から構成されるプロジェクトでコーディングを行うにあたっては、他人が見た場合にも判りやすいかどうかという点は意識しなければならない。 見やすさを重視する事は、忘れた頃にメンテナンスする ( 可能性がある ) 自分のためにもなる。 ここではjavaを開発言語にしたアプリケーション開発プロジェクトにおける、コーディングルール、推奨を記す。 単純に「ここに記載されている事だけ気を付ければよい」という事ではなく、判りやすいコードを書くという視点を忘れずに柔軟にコーディングを行って頂きたい。 ※ 叩き台として作成したものなので、あくまで参考用。プロジェクトや利用者毎に適宜変更推奨。 ファイル</h2> publicクラスはそのクラス名の1ファイルにする。 複数のpublicクラスを1つのファイルに書いてはいけない。</li> 非publicのクラスで、他クラスから利用されないものに関してはそのクラスが利用されるpublicクラスのファイルに含めてもよい(インナークラス)。ただし、インナークラスは原則利用しない事。</li> </ul> ファイルエンコードはUTF-8とする。 ファイルの階層構造</h2> Mavenの標準ディレクトリレイアウトに従う。 MavenはJavaのビルドツールのデファクトスタンダートとして長期間利用されており、Mavenの標準ディレクトリレイアウトを利用する事で、多くのJava開発者にとって見通しのよいレイアウトになる。 命名規則</h2> 大文字小文字</h3> Javaでは大文字と小文字を区別するが、大文字/小文字の違いによって区別をするコードを書いてはいけない。 悪い例) private int num; private int Num; </code></pre> 良い例) private int cartNumber; private int productNumber; </code></pre> パッケージ名</h3> "." で区切られた文字列(英子文字)とし、アプリケーション/プロジェクトを表す名前を含める。</li> 外部公開予定であれば基本的にはドメイン名を含める。</li> </ul> 例) com.mosaos.projectname</code> クラス名</h3> アッパーキャメルケースを用いる。 例) UpperCamelCase</code> 例外クラス名</h3> 最後をExceptionとしたクラス名とする。 インターフェース名</h3> クラス名と同じ。 実装クラス名</h3> 特にインターフェースと区別する必要があるのであれば、最後に Impl を付与する。 抽象クラス名</h3> 適当な名前が無い場合、Abstractからはじまりサブクラスを連想させる名前を付ける。 尚、むやみに抽象クラスを作成する事はおすすめしない。Templateパターン等明らかな目的がある場合を除き、本当に抽象クラスが必要なのか考える事。 以下のような理由での抽象クラス作成(継承の利用)は控える事。 メソッド共有のための継承共通メソッドの変更/機能追加が難しくなる。</li> 基底クラスに共通メソッドが追加されまくり、ネ申クラスが誕生する。</li> </ul> </li> メンバ変数の共有のための継承派生クラスへの影響があるため、メンバ変数を変更しにくくなる。</li> </ul> </li> </ul> 定数(static final)</h3> 大文字スネークケースを用いる。</li> </ul> 例) UPPER_SNAKE_CASE</code> メソッド名</h3> ローワーキャメルケースを用いる 例) lowerCamelCase</code> 操作を行うメソッドに関しては動詞 + 対象となるような名称にする事。対象 + 動詞ではない。 悪い例) couponGet</code> 良い例) getCoupon</code> 属性取得</h4> 属性取得のメソッドには getXxx</code>, isXxx</code> ( xxx は属性名 ) 形式のメソッド名を用いる。 属性設定</h4> 属性設定のメソッドには setXxx</code> ( xxx は属性名 ) 形式のメソッド名を用いる。 英語と日本語</h3> すべての識別子の名前は英語を基本とする。例外的に英語化が困難な対象に関してはローマ字表記も認めるが、可能な限り対応用語辞書を作成 / メンテナンスし、同一の用語に対して異なる命名をしないようにすること。 名前の対称性</h3> 命名する場合に、以下のような英語の対象性に気を付けること。 add / remove</li> insert / delete</li> get / set</li> start / stop</li> begin / end</li> send / receive</li> first / last</li> get / release</li> put / get</li> up / down</li> show / hide</li> source / target</li> open / close</li> source / destination</li> increment / decrement</li> lock / unlock</li> old / new</li> next / previous</li> </ul> ループカウンタ</h3> スコープが狭いループカウンタには、i</code>, j</code>, k</code> を用いる スコープが狭い変数</h3> スコープが狭い変数名には省略形を用いても構わない。ただし省略形ばかりで可読性が低くなってはならない。 例) InputStream in = new BufferedInputStream(...); </code></pre> 意味が判る名前</h3> 原則として名前から意味が判るような名前にする事。 悪い例) copy(s1, s2); </code></pre> 良い例) copy(source, destination); </code></pre> スタイル</h2> コーディングスタイルは JDKソースのスタイルに準ずる。 K&RのC言語のスタイルと同様だが、クラス/メソッド定義開始の"{"は改行せずに記述する。 スタイルのチェックは checkstyle</a> を利用して、可能な限り自動化する事。 コメント</h3> publicなクラス/メソッドには原則Javadocコメントを記載する事。 </li> コメントは必要なものを簡潔に記載する。 </li> コメントには、なぜそうなのかを書く。 </li> コードを書く前に先にコメントを記述する。やってみると判るが良いコメントを書くための最上の方法の一つは、コードを書く前に処理内容を端的にコメントとして記載する事。複数のステップから構成される処理であれば、ステップ毎に行を分けてコメント記載し、それからコーディングに取り掛かる。こうすれば必ずコメントが書かれるし、コメントに記載した通りの処理が実装される事につながります。 </li> TODO</code> コメントを活用する事。 Eclipse等のIDEで TODO</code> はまとめて参照可能なので、(他者の実装待ちや仕様確定待ち等の理由で)残タスクとして残っている部分には TODO</code> コメントとして後から行うべき事を書いておきましょう。 ※ Eclipseで一覧表示する場合にはタスクビュー</code>を利用してください。 ※ TODO 以外にも以下のようなコメントで利用可能なタスクタグがある。 FIXME</code> : 修正が必要</li> XXX</code> : 危険！動くけどなぜうごくかわからない。</li> </ul> ※ FIXME,XXX以外もあるが、Eclipseで利用する場合、 [設定</code>]＞[Java</code>]＞[コンパイラー</code>]＞[タスク・タグ</code>]で利用するコメントを追加する必要がある。 </li> </ul> import</h3> import文で *</code> は原則使わない。 スコープ</h3> メソッド、フィールドには適切なスコープを設定する事。 インスタンス変数</h3> 原則 private</code> スコープとし setter/getter を必要に応じて記述する。単純に値を設定/取得するだけの setter/getter については適宜 Lombok</a> を利用してコードの可読性や開発効率を高める事。 ローカル変数の利用</h3> エンティティクラスや Bean クラス等を除き、インスタンス変数の利用は可能な限り避ける事。特に Spring Framework 等の DI コンテナを利用する場合、ある種のクラスはシングルトンとしてインスタンス化される事がデフォルト設定の場合もあるため、インスタンス変数を不用意に利用した場合スレッドアンセーフな実装となる。この結果、単体や結合試験ではバグを発見できず、実運用で初めて不具合が発生する可能性がある。場合によっては個人情報の漏洩等の重篤な問題を引き起こす可能性もあるため、利用する際は注意して実装を行う事。 finalの使用</h3> 必要に応じて final を適切に利用する。 継承され(たくない)ないクラス</li> オーバーライドされ(たくない)メソッド</li> 値の変わらない(変わってはまずい)変数</li> </ul> 比較</h3> オブジェクトの比較には equals</code> メソッドを利用する。インスタンスが同一かどうかを比較したい場合に ==</code> 比較を行うのは構わない。 booleanの比較</h3> 条件式でbooleanの変数を比較しない 悪い例) if (isEmpty == true) </code></pre> 良い例) if (isEmpty) </code></pre> ループ</h3> 拡張forループが利用可能である場合には拡張forループを使う事。 インターフェースでの参照</h3> 原則としてオブジェクトの参照にはインターフェースを利用する。特にJava APIの利用等において以下のようなコーディングをたまに見かけるが、良くない実装なので止める事。 悪い例) ArrayList<Entry> list = new ArrayList<Entry>(); </code></pre> 良い例) List<Entry> list = new ArrayList<Entry>(); </code></pre> 数値</h3> 必要に応じて BigDecimal</code> クラスを適切に利用する事。プリミティブ型や BigDecimal 以外の型における算術演算では厳密には誤差が発生する場合がある。金融系や科学技術系等の処理で正確な演算が必要な場合には BigDecimal の利用が適している。 try with resources</h3> ストリーム等リソース解放を必要とするクラスを利用する場合、可能であれば try with resources を利用する事。 文字列連結</h3> 特にループ処理等で文字列連結を行う等、文字列連結処理でのパフォーマンスが懸念される場合には StringBuilder</code> (あるいはStringBuffer)を利用する事。 ※スレッドセーフでない箇所で利用する場合にはStringBufferを利用する System.out.print の利用</h3> ログ出力API等に置き換える。標準出力がどうしても必要である場合や、自身の一時的なデバッグ目的で利用する場合を除いて、プロダクトレベルのアプリケーションでの System.out.print</code>, System.err.print</code> 系の利用は行わないこと。 出力元の特定が困難</li> ログ出力APIであればログフォーマットの設定によって出力箇所の特定は容易であるし、出力先やレベルの変更等一括して行える。</li> </ul> ラムダ</h3> ラムダ式が利用できる箇所はラムダ式を利用してよい。 Stream API</h3> 利用してよい。ただし、Stream APIは中間処理のたびにインスタンスが生成されるため、拡張forを利用する場合に比べてパフォーマンスが劣化する可能性がある。パフォーマンス重視の処理を実装する場合には各方式でパフォーマンス計測する等してから実装方式を決める事をおすすめする。 var (Local-Variable Type Inference)</h3> var は原則利用しない。 TypeScript などの普及でも判るが、現代のチーム開発では型安全性</code>の確保が強く求められている。型推論による省力化よりも、コードの堅牢性を優先すべき。ただし、スコープの都合などで var を使わないデメリットが非常に大きい例外的なケースに限り、利用を認める。 KVM ゲストでコンソールログイン可能にする 2026-09-22T00:00:00+00:00 KVM にはゲストにコンソールログインするための機能が備わっていますが、ゲスト自体がコンソールログイン可能に設定されていない場合、接続を行っても何も操作が行えません。 特にゲスト OS のネットワーク設定が行えていない場合には、コンソールログイン可能であると作業が捗ります ( SSH 接続して設定を行う事もできないので )。 以下では KVM ゲストの設定方法を記します。 環境</h2> KVMホスト OS : Rocky Linux 9 (CentOS 8からアップグレード)</li> ブートローダー : grub2</li> </ul> 利用している KVM 環境は Rocky 9 上に構築してあるのですが (KVMサーバがRocky9: CentOS からアップグレード)、ゲストも主に RHEL系を利用します。また、毎回 OS を新規利用するのではなく、ベースとなるイメージを作成しておき、新規に KVM ゲストを作成する場合には、このベースイメージをクローンする方式を採ります。こうする事でベースイメージにコンソールログイン可能な設定を行っておけば、クローンしたゲストでもコンソールログイン可能になります。 ※ RHEL7系 ( CentOS7 等 ) 以降で使える手順です。それ以前は grub2 ではなく grub なので別手順になります。 ※ 本記事は CentOS 8 時代に執筆・検証した内容をベースにしています。そのため、以降の出力ログやカーネル、glibc などのバージョン表記は当時のままとなっていますが、RHEL 8/9 系および Rocky Linux 9 でも同様の手順で設定可能です。 設定</h2> /etc/default/grub の編集</h3> Grub の設定を変更します。 vi /etc/default/grub </code></pre> 以下部分を GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap"; </code></pre> 以下のように変更します。 ( 既存の設定に console=tty0 console=ttyS0,115200n8r</code> を追記 ) GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap console=tty0 console=ttyS0,115200n8r" </code></pre> 編集後定義生成コマンドを実行します。 grub2-mkconfig -o /boot/grub2/grub.cfg </code></pre> 再起動</h3> Grub の設定変更後再起動します。 reboot </code></pre> 確認</h2> 再起動したら、KVMホストから接続できるか確認しておきましょう。 実行中のゲストを確認 virsh list --all Id 名前状態 ---------------------------------------------------- 1 mosaos-centos8 実行中 5 centos8-base 実行中 </code></pre> コンソールログインします virsh console centos8-base ドメイン centos8-base に接続しました エスケープ文字は ^] です CentOS Linux 8 (Core) Kernel 4.18.0-193.el8.x86_64 on an x86_64 Activate the web console with: systemctl enable --now cockpit.socket localhost login: </code></pre> ここから後はローカルでのログインと同様に作業を行えます。 login プロンプトが表示されない場合は、一度リターンキーを叩きましょう。 抜ける場合は最初に書いているように ^]</code> ( Ctrl</code> + ]</code> ) で可能です。 ※ Cockpit</a> も導入しているが、Cockpit からもコンソールログイン可能です。 AWSコンソールからログインできる感じに似てるかも。 KVM ゲストのディスクサイズ変更 2026-09-22T00:00:00+00:00 KVMゲストの用途によっては最初に作成したディスクでは容量が足りなくなる事が時々あります。 CPUやメモリリソースに関しては、一旦再起動が必要ですが比較的簡単に変更可能です ( KVMホストのリソースで制約は受ける )。 ディスクに関してもNFS等で外部のディスクをマウントしている場合は柔軟に設定変更が可能ですが、イメージ自体のディスク容量を変更する場合にはそれなりの作業が必要になり、どこかに書いておかないと忘れる系なので、手順を書いておきます。 環境</h2> 環境は以下になります。 KVMホストOS : Rocky9</li> KVMゲストOS : Linux系 ( LVM 利用 )</li> </ul> 私はイメージファイルのフォーマットは qcow2 形式となっているので qcow2 での手順になります。 手順</h2> ※ 作業をはじめる前に、ディスク容量を変更するKVMゲストはシャットダウンし、必要に応じてイメージのバックアップを取りましょう。 ※ コマンド操作を失敗した場合最悪起動不能になるため、バックアップする事をお勧めします。 先ずは KVMホスト上で作業します。 KVMイメージのチェック</h3> KVMイメージのフォーマットとサイズをチェックします。 qemu-img info /var/lib/libvirt/images/<イメージファイル名> </code></pre> ファイル容量の拡張</h3> qemu-img resize -f qcow2 <イメージファイル名> +10G </code></pre> ※ +10G</code> の部分はリサイズする量に合わせて適宜変更して下さい。 実行後は qemu-img info</code> を再実行し、サイズが正しく変更されている事を確認しましょう。 これ以降は、KVMゲストでの操作になります。 fdisk による操作</h3> 容量を増やしたイメージでKVMゲストを起動します。 fdisk を実行して、ディスクを切り直します。 ※ デバイス名は環境に併せて適宜変更して下さい。 ※ 途中で説明入ってますが、q</code> 入力までは fdisk コマンドでの操作になります。 fdisk /dev/vda </code></pre> 状態を確認します。 コマンド (m でヘルプ): p ( 中略 ) デバイス 起動開始位置終了位置セクタサイズ Id タイプ /dev/vda1 * 2048 2099199 2097152 1G 83 Linux /dev/vda2 2099200 41943039 39843840 19G 8e Linux LVM </code></pre> /dev/vda2 の LVMをリサイズします。 一旦削除して、 コマンド (m でヘルプ): d パーティション番号 (1,2, 規定値 2): 2 </code></pre> 作成しなおし。基本パーティションの2 を削除しているので基本パーティションの2を作成しなおします。セクタ数を入力する部分は既定値(リターンのみ)でOKです。 ( 空き容量をすべて使う形で作成される ) コマンド (m でヘルプ): n パーティションタイプ p 基本パーティション (1-4) e 拡張領域 選択 (既定値 p): p パーティション番号 (2-4, 既定値 2): 2 最初のセクタ (2099200-41943039, 既定値 2099200): 最終セクタ, +セクタ番号または +サイズ{K,M,G,T,P} (2099200-41943039, 既定値 41943039): 新しいパーティション 2 をタイプ Linux、サイズ 19 GiB で作成しました。 パーティション #2 には LVM2_member 署名が書き込まれています。 署名を削除しますか？ [Y]es/[N]o: N </code></pre> Linux LVM にタイプ変更</h3> 作り直したパーティションタイプは Linux</code> なので Linux LVM</code> に変更します。 コマンド (m でヘルプ): t パーティション番号 (1,2, 既定値 2): 2 16 進数コード (L で利用可能なコードを一覧表示します): 8e パーティションのタイプを 'Linux' から 'Linux LVM' に変更しました。 </code></pre> 変更後の状態を確認し、 コマンド (m でヘルプ): p (中略) デバイス起動開始位置終了位置セクタサイズ Id タイプ /dev/vda1 * 2048 2099199 2097152 1G 83 Linux /dev/vda2 2099200 41943039 39843840 19G 8e Linux LVM </code></pre> 想定している状態 ( サイズ, パーティションタイプ ) に変更されていたら、書き込み、fdisk を終了します。 コマンド (m でヘルプ): w コマンド (m でヘルプ): q </code></pre> 現行のOS ( Redhat7以降 ) ならば partprobe</code> で再起動不要かと思います。 ※ OSによっては再起動が必要かもしれません。 ※ partprobe</code> すら不要かも。 partprobe </code></pre> 物理ボリュームのサイズ変更</h3> LVMを利用している場合、PV(物理ボリューム), LV(論理ボリューム) を変更する必要があります。 先ず PV ( PhysicalVolume ) をリサイズします 現在の状態を確認し、 pvdisplay </code></pre> リサイズします。 fdiskで変更したサイズ全てを利用するように変更が行われます。 pvresize /dev/vda2 </code></pre> サイズ変更後は pvdisplay 再実行して変更確認しておきましょう。 論理ボリュームのサイズ変更</h3> 論理ボリュームをリサイズします。 現在の状態を確認し、 lvs lvdisplay </code></pre> リサイズします。 lvextend -l +100%FREE /dev/cl/root </code></pre> 最後にファイルシステムを拡張。 xfs_growfs /dev/cl/root </code></pre> ※ Ubuntu の場合 resize2fs /dev/ubuntu-vg/ubuntu-lv</code> とかに変える必要があるかもしれません。 サイズ確認 df evtmpfs 912992 0 912992 0% /dev tmpfs 930236 0 930236 0% /dev/shm tmpfs 930236 8796 921440 1% /run tmpfs 930236 0 930236 0% /sys/fs/cgroup /dev/mapper/cl-root 17811456 8021136 9790320 46% / /dev/vda1 999320 262420 668088 29% /boot tmpfs 186044 0 186044 0% /run/user/1000 </code></pre> 容量が拡張されていれば成功です。 Nexus Repository Manager による Dockerリポジトリ構築 2026-09-22T00:00:00+00:00 はじめに</h2> ※ この記事は過去記事のリライトで、情報が古くなっている可能性があります。ただし、この手順で構築した NXRM は現在 ( 2026/9 ) も稼働しています。 Docker 利用が増えているようですが、Docker イメージの共有ができておらず、利用する場合には Dockerfile から個々の開発者がビルドする必要があるなど、利便性の点で難がありました。 この問題を解決するためのDockerリポジトリを構築したので、構築/利用手順を以下に示します。 リポジトリ構築には Nexus Repository OSS</a> ( NXRM</code> ) を利用しました。 NXRM は Docker リポジトリ以外にも、maven 等の各種ライブラリ/イメージのリポジトリとして利用可能な OSS です。 Docker-hub のプロキシとして動作する事も可能、且つ、グループリポジトリ機能で独自(hosted)リポジトリとマージする事で、内部と外部(キャッシュ)リポジトリを透過的に扱う事も可能です。 ECR ( Elastic Container Registry) 等を利用することもできますが、コスト面などで採用しにくいチームなどでも採用しやすい。 ※ 社内 LAN 等では Docker Imageや各種ライブラリをキャッシュしてトラフィックを削減する事も可能になる。 ※ gitlab ci 等でイメージビルド後 NXRM に登録 ( push ) といった運用も可能。gitlab も self hosted 可能。 利用する事で、リポジトリ問題を解決する事が可能かもしれません。上記のような問題がある場合、試してみるとよいでしょう。 環境</h2> OS : CentOS8</code> ( KVM ゲストで構築) 現在は Rocky9</code> にアップグレードしてある</li> リポジトリディレクトリはホストのディレクトリをマウントする。キャッシュはリポジトリのサイズは肥大化しがちなので、KVMゲスト上で管理するよりホストディレクトリをマウントする方が管理がしやすい。</li> 最初 9p_virtio を使おうとしたが、うまくいかなかったので NFS を使う。</li> Configuring Blob Stores</a> に NFS は v4 使えとあったので NFSv4 を利用。</li> 事前にKVMホスト側でNFSサーバを設定しておく。</li> ホストのディレクトリは /var/opt/nexus</li> </ul> 前提</h2> 内部アクセスのみの閉じた環境で運用するためTLS(HTTPS)化は行っていません。 ※NXRMをTLS化する場合、複数の方法があります。公式ドキュメント等を参考にしてください。</li> nexus_hostname</code> が Nexsus Repository Managerをインストールしたホスト名です。ホスト名アクセスが不可の場合IPアドレスでも構いません。</li> </ul> インストール手順(サーバ)</h2> dnf update</h3> dnf update </code></pre> nfsクライアント設定</h3> KVMホストのディレクトリをNFSマウントします。 パッケージインストール</h4> dnf -y install nfs-utils </code></pre> 設定ファイルの編集</h4> vi /etc/idmapd.conf </code></pre> 以下部分を編集 Domain = mosaos.local </code></pre> マウント</h4> マウントできるか確認し、 mount -t nfs kvmhost:/var/opt/nexus /mnt </code></pre> OKなら umount umount /mnt </code></pre> /etc/fstab に設定を記載し、automount されるようにする。 vi /etc/fstab </code></pre> 以下を追記 kvmhost:/var/opt/nexus /opt/sonatype-work nfs4 rw,sync,tcp,hard,intr,rsize=32768,wsize=32768 0 0 </code></pre> マウント。 mount -a </code></pre> NXRMインストール</h3> ansible-playbook を利用してインストールする。 mosaos/sonatype-nexus3-ansible</a> プロジェクトをclone git clone https://github.com/mosaos/sonatype-nexus3-ansible </code></pre> ansible-playbook cd sonatype_nexus3_ansible ansible-playbook -i hosts site.yml </code></pre> NXRM設定</h3> ほぼ以下の通り Using Nexus 3 as Your Repository - Part 3: Docker Images</a> 以下リポジトリを作成 名前</th> 種類</th> ポート(HTTP)</th></tr></thead> docker-private</td> docker(hosted)</td> 5001</td></tr> docker-hub</td> docker(proxy)</td> -</td></tr> docker-group</td> docker(group)</td> 5000</td></tr> </tbody></table> それぞれの作成時の設定内容は以下 docker-private</h4> docker(hosted)で作成</li> HTTPをチェックしポート番号を指定 (5001)</li> Enable Docker V1 API:</code> をチェック</li> </ul> docker-hub</h4> docker(proxy)で作成</li> Remote storage:</code> に https://registry-1.docker.io</code> を指定</li> Docker Index:</code> は User Docker Hub</code> を選択</li> Enable Docker V1 API:</code> をチェック</li> </ul> docker-group</h4> docker(group)で作成</li> HTTPをチェックしポート番号を指定 (5000)</li> Member repositories:</code> に先に作成した二つのリポジトリを追加</li> Enable Docker V1 API:</code> をチェック</li> </ul> ※ 私の環境では Enable Docker V1 API:</code> をチェックしてないと push できませんでした。 firewall設定(追加)</h3> リポジトリ作成後は NXRMをインストールしたホストで 5000/tcp, 5001/tcp を許可する。 firewall-cmd --add-port=5000/tcp --permanent --zone=public firewall-cmd --add-port=5001/tcp --permanent --zone=public firewall-cmd --reload </code></pre> インストール手順(クライアント)</h2> docker 環境を構築してください。 非TLSのリポジトリに接続させるためには設定が必要です。 環境</h3> 以下環境で確認しています。 OS : CentOS8</li> Docker : 19.03.8</li> </ul> 疎通確認</h3> curlでNXRMにリクエストを投げた際に、Dockerリクエストではない旨レスポンスが返ってくればOK。 curl http://nexus_hostname:5000/ <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <title>Error 400 Not a Docker request</title> </head> <body><h2>HTTP ERROR 400 Not a Docker request</h2> <table> <tr><th>URI:</th><td>/</td></tr> <tr><th>STATUS:</th><td>400</td></tr> <tr><th>MESSAGE:</th><td>Not a Docker request</td></tr> <tr><th>SERVLET:</th><td>-</td></tr> </table> <hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.30.v20200611</a>< hr/> </body> </html> </code></pre> daemon.json の設定</h3> daemon.jsonを作成し、Dockerの設定を記述します。 vi /etc/docker/daemon.json </code></pre> TLS化していないリポジトリを利用する場合 insecure-registriesで指定する必要があります。 ※毎回コマンドラインで指定する事も可能ですが、面倒なのでdockerのdeamon設定がお勧め。 insecure-registries</code> で、NXRMで追加したレジストリを追加してください。 { "debug": true, "insecure-registries": ["nexus_hostname:5000", "nexus_hostname:5001"] } </code></pre> ※ミラー設定も行った場合の設定は下で記載しています。 daemon.json作成後はDockerデーモンを再起動。 systemctl restart docker </code></pre> Dockerイメージの登録(push)</h2> NXRMにログイン</h3> ユーザ / パスワードは NXRMのユーザを指定します。 docker login nexus_hostname:5000 docker login nexus_hostname:5001 </code></pre> 実行すると Username, password 入力を求められるので、自身のアカウントでログインして下さい。 実施時に WARNING 出力されますが、Login Succeeded</code> になれば login 成功です。 ※コマンド実行後は ~/.docker/config.json</code> に認証情報が記録されます。 push</h3> hosted リポジトリに pushします。 docker tag イメージ名:バージョン nexus_hostname:5001/イメージ名:バージョン docker push nexus_hostname:5001/library/イメージ名:バージョン </code></pre> 何故か、library</code>付けないとpull時点で 404(NOT FOUND)になった。 ※おそらく docker-hub と同じように accountname/imagename:version</code> のようなタグ付けをしないと駄目な気がする。公式イメージの場合には accountname部分がないが、こういうタグ付けの場合には library 以下になっている風。実際に公式mariadbを落としてきてproxyリポジトリに格納されているのを見ると name = library/mariadb</code> となっている。 pull</h3> push したイメージが取得できるか確認取得先は登録したhostedではなくhostedとproxyをまとめているgroupリポジトリを指定しています。 docker pull nexus_hostname:5000/イメージ名:バージョン </code></pre> ミラー設定</h2> ここまでの設定で、独自に作成したDockerイメージをリポジトリサーバに登録(push)、及び、取得(pull)できる事が確認できましたが、この状態では独自イメージと外部(docker-hubでホストされている)イメージを透過的に扱う事ができません。 これを透過的に扱えるように設定を変更します。 具体的には、自分でホストしているイメージ取得の場合でも以下のように、リポジトリサーバ:ポートを指定しないで取得できるようにします。 ※push時にはリポジトリサーバ:ポートを指定しなければいけません。 docker pull イメージ名:バージョン </code></pre> docker では、registry-mirrors を利用する事で、docker-hubのミラーとして設定できるので、作成したgroupリポジトリを設定する事で対応可能なはずですが、 ミラーサイトに対して正しく認証情報が渡されない問題があるため、仕掛けが必要になります。 参考 : registry-mirrorsが機能しない</a> 対応方法としては、 Docker is not passing auth informations when pulling from a mirror registry #30880</a> にある認証情報をNginx(proxy)側で上書きしてNexusにアクセスさせる方法を採ります。 nginx設定の編集</h3> 最終的に以下のような設定にしました。 events { worker_connections 1024; } http { proxy_send_timeout 120; proxy_read_timeout 300; proxy_buffering off; keepalive_timeout 5 5; tcp_nodelay on; log_format upstreamlog [$time_local] $remote_addr - $host - $upstream_addr - $request; access_log /var/log/nginx/upstream.log upstreamlog; server { listen *:80; server_name www.example.com; # allow large uploads of files client_max_body_size 1G; # optimize downloading files larger than 1G #proxy_max_temp_file_size 2G; location ~ ^/(v1|v2)/ { if ($authorization = '') { set $authorization "Basic XyzAbCdefg1234567890Mzk2Zi00NWYxLWJiNjYtN2ExOWRkM2EyOTVk"; } proxy_pass http://127.0.0.1:5000; proxy_set_header Authorization $authorization; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; } location / { # Use IPv4 upstream address instead of DNS name to avoid attempts by nginx to use IPv6 DNS lookup proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } } </code></pre> リポジトリアクセスする場合 /v1 or /v2 で始まるURLにアクセスされるので、この場合にgroupリポジトリに転送します。この際、proxy_set_header Authorization ...</code> で認証情報を設定しています。 $authorization</code> に設定する基本認証の値は以下のようにして生成可能です。 echo -n 'username:password' | base64 </code></pre> また、上記設定では実際の転送先を確認するためupstreamlog</code>を出力するように設定しています。 上述した、library</code>を付けてpushしないと pull できなかった問題はこのログの確認で気づきました。 pushは出来たがpullできない場合で、404が発生している場合、dockerクライアントがmanifestsを取得するURLがpushした先と異なっている可能性があります。この場合にはuplstreamlogの確認で解決するかもしれません。 nginx再起動</h3> 設定に問題ないか確認し、 nginx -t </code></pre> 問題なければ再起動します。 systemctl restart nginx </code></pre> クライアント側設定</h3> /etc/docker/daemon.json を以下に書き換えます。 registry-mirrors</code>、及び、insecure-registries</code> で nexusのホストを指定しています。 { "debug": true, "insecure-registries": [ "nexus_hostname", "nexus_hostname:5000", "nexus_hostname:5001" ], "registry-mirrors": [ "http://nexus_hostname" ] } </code></pre> トラブルシュート</h2> ミラー設定が一番ハマりました。 問題発生時には以下内容の確認をお勧めします。 docker(クライアント側)ログ私の構築した環境ではsyslog(/var/log/message/)に出力</li> nexus repository managerのログ /opt/sonatype-work/nexus3/log</code> が出力先です。</li> nginxのログ proxyしている場合、上述のupstreamlogも利用しましょう。</li> </ul> リクエスト先が正しくない</h3> library</code>付けずにpushした場合、hostedリポジトリに以下のような構造でpushされました /v2 |- blobs | |- sha256:..... | |- sha256:..... | |- sha256:..... | |- sha256:..... |- image_name |- manifests | |- sha256:... |- tags |- latest </code></pre> この状態でミラー設定を行い docker pull image_name</code> するとdockerログには以下のエラーが出力 Oct 13 02:36:40 localhost dockerd[17647]: time="2020-10-13T02:36:40.054981034-04:00" level=info msg="Attempting next endpoint for pull after error: Get https://nexus_hostname:5000/v2/library/image_name/manifests/latest: unauthorized: access to the requested resource is not authorized" </code></pre> /v2/library/image_name/...</code> にアクセスしている(らしい)事が判りました。 (実際はこの前にupstreamlogで気づく) 以下でpushし直した後、pullできる事を確認しました。 docker push nexus_hostname:5001/library/image_name:latest </code></pre> docker pull image_name </code></pre> 参考</h2> Using Nexus 3 as Your Repository - Part 3: Docker Images</a></li> Installation</a></li> Configuring Blob Stores</a></li> NFS v4の設定内容まとめ</a></li> registry-mirrorsが機能しない</a></li> Docker is not passing auth informations when pulling from a mirror registry #30880</a>"</li> </ul> 陶器のウミウシたち 2026-09-22T00:00:00+00:00 動機</h2> 亡き妻 ( NYC SVA 卒。肺腺癌で夭折 ) がポタリーペインティングを行っていたのだが、私の方ではポタリー粘土で形を作って、いくつかの陶器フィギュアを作っていたことがあった。 ウミウシ。 ウミウシの写真集を見て、美しさに感動した頃の作。 その後</h2> 妻のポタリーの個展などに出品していたのだが、いつのまにか全部いなくなってたのだ。買ってくれた人の下に今もいるかもなのだ。 ウェディングドレス 2026-09-22T00:00:00+00:00 なぜ作った？</h2> 亡き妻 ( NYC SVA 卒。肺腺癌で夭折 ) は結婚式で自分がイメージしたドレスが来たかったらしく、そのイメージに近いドレスを作製したのだｗイメージは妖精。普通のウェディングドレスとは異なる、胸から一枚の布がふわっと広がる感じ。前部分は膝上でくるっと内に巻いている感じで、後ろは普通のウェディングドレスと同様にドレープが自然に流れる感じ。 ドレス選びの時に見たのだが、イメージに合うようなドレスは無し。という事で作ることに(私が..) 材料調達</h2> 日暮里繊維街に布を探しに行き、トマトで布をゲット。パニエがないと綺麗なラインにはならないのでパニエも作成(こっちの方が時間がかかった記憶がある)。 このドレス、妻の友人が「着たい！」とかで妻は太っ腹にあげてしまったのだ。 ボディバッグ 2026-09-21T00:00:00+00:00 亡き嫁にもらったボディバッグがボロボロになったので作った自作ボディバッグ。本体部分はボロボロになったのだが、ベルト部分は全然問題なかったので、ベルト部分は再利用している。革はハンズでたまたま良さげなの売ってたのでそれで作成。 底部分は切り替えて黒の革を利用。革部分は手縫い。内袋はミシンで。

mosaos

スピーカー保護回路基板を改造する

改造</h2> 上記改造を施した基板の写真を最初に示す。</p> この時点では改造箇所は３か所 (section1 - section3)</p>

Zola daisyUI blog

はじめに</h2> Zola + daisyUI 使ったブログテンプレート作ったので、備忘録かねて記事にしてます。</p> 作った理由、セットアップ手順等を記しています。</p>

なぜ作ったか？</h2> 以前から Github pages での個人情報発信は考えていたのだが、ようやく重い腰を上げてアプリを構築した。</p>

機能</h2> 作ったテンプレ。詳細は README.md 参照なのだが、以下のようになっている。 ※ ほぼほぼ Zola/daisyUI 等の特性ではある。</p>

開発環境</h2> 以下で確認しています。</p>

GithHub Actions ワークフローの作成</h3> アプリ側のリポジトリ ( my-portfolio</code> ) のルートに、GitHub Actions 用の設定ファイルを作成する。</p> ※ 作者の設定になっているので適宜変更すること</p>

アプリ側 ( my-portfolio ) の設定</h3> アプリ側の .github/workflows/deploy.yml</code> の on:</code> セクションを書き換えて、コンテンツ側からの合図 ( repository_dispatch ) を待ち受けられるようにします。</p>

コンテンツ側 ( my-portfolio-content ) の設定</h3>

zola-daisyui-blog の更新に追随する</h2>

About Me

テクニカルスキル</h2> 言語:</strong> Java (Spring/Seasar2), C#, C++, C, Python, PHP, JavaScript (React), etc.</li> DB:</strong> MySQL, PostgreSQL, Oracle, DB2</li> インフラ:</strong> AWS, Docker, k8s, KVM, Linux, OpenVPN, GitLab-CI, Sentry, Metabase, etc.</li> </ul>

ベストプラクティス cron

開発</h2> まずは開発 ( cron実装/設定者 ) 寄りのプラクティスから。</p>

多重起動を防ぐ</h3> アプリケーションを実装する場合には、処理言語系 ( Java 等 ) で多重起動を防ぐための仕組みを利用するのも可だが、Linux の標準ツールである flock</code> を使う事で多重起動を防ぐ事が可能。</p>

スクリプト</h4> 処理内容を含むスクリプトを作る。 /root/scripts/sleep.sh を以下で作成。</p>

cron 設定</h4> cron 設定は /etc/cron.d/test ファイルを作る。</p>

運用</h2> 運用寄りのプラクティス。</p>

ベストプラクティス GitLab

はじめに</h2> 個人で GitHub 使ってたり、業務で GitLab 使っている中で、</p> うまくいった事・うまくいかなかった事 いずれもあるわけですが、これら経験を踏まえて、</p>

カンバン用</h3> Doing</code> 実行中。色は #5CB85C</li>

Close 系</h3> Closed issue の分類に利用。色は #808080</p>

見積もり</h3> issue のコメントで /estimate 1w 2d 5h</code> といった風に入力する事で見積もり工数を入力できます。</p>

それでも発生した問題</h2> 上記のようなルールを策定しても、問題が発生する事はあります。 具体的例を示します。</p>

何する issue ?</h3> タイトルだけや、概要説明が不十分な issue が作られ、何するの?状態になった事がありました。</p> 流れを書くと、以下のような感じ</p>

まとめ</h2> 権限まわりザルな設定するのはホント止めた方がよいと思う。</p>

Oracle ユーザ管理ベストプラクティス

用語</h2> 用語をいくつか定義しておきます。</p>

ベストプラクティス</h2>

ユーザではなくロールに権限を付与する</h3> オラクルには ロール(ROLE) を扱う仕組みがあるので、 個別ユーザに権限を与えるのではなく ROLE に権限を割当て、個々のユーザはロールに属するよう設定を行います。</p>

監査を行う</h3> オラクルにはログインの試行や作業内容を監査するための仕組みが存在します。 監査が無効な場合には、必要十分な監査が行えるように監査を有効にしましょう。</p>

ロールを入れ子にする</h3> Oracle のロールはネストする事が可能です。 個人的に設定した事はないのですが、以下のような設定を行っているのを見たことがあります。</p>

PUBLIC に注意する</h3> PUBLIC に権限を付与すると、誰でもその権限を使用できるようになります。</p> [第22回] PUBLICに注意</a></p>

ベストプラクティス Redmine

コーディングルール (Java)

ファイル</h2> publicクラスはそのクラス名の1ファイルにする。</p>

命名規則</h2>

大文字小文字</h3> Javaでは大文字と小文字を区別するが、大文字/小文字の違いによって区別をするコードを書いてはいけない。</p> 悪い例)</p>

インターフェース名</h3> クラス名と同じ。</p>

実装クラス名</h3> 特にインターフェースと区別する必要があるのであれば、最後に Impl を付与する。</p>

ループカウンタ</h3> スコープが狭いループカウンタには、i</code>, j</code>, k</code> を用いる</p>

改造</h2>
上記改造を施した基板の写真を最初に示す。</p>
この時点では改造箇所は３か所 (section1 - section3)</p>

はじめに</h2>
Zola + daisyUI 使ったブログテンプレート作ったので、備忘録かねて記事にしてます。</p>
作った理由、セットアップ手順等を記しています。</p>

GithHub Actions ワークフローの作成</h3>
アプリ側のリポジトリ ( `my-portfolio</code> ) のルートに、GitHub Actions 用の設定ファイルを作成する。</p>`
`※ 作者の設定になっているので適宜変更すること</p>`

アプリ側 ( my-portfolio ) の設定</h3>
アプリ側の `.github/workflows/deploy.yml</code> の on:</code> セクションを書き換えて、コンテンツ側からの合図 ( repository_dispatch ) を待ち受けられるようにします。</p>`

テクニカルスキル</h2>

言語:</strong> Java (Spring/Seasar2), C#, C++, C, Python, PHP, JavaScript (React), etc.</li>
DB:</strong> MySQL, PostgreSQL, Oracle, DB2</li>
インフラ:</strong> AWS, Docker, k8s, KVM, Linux, OpenVPN, GitLab-CI, Sentry, Metabase, etc.</li> </ul>

開発</h2>
まずは開発 ( cron実装/設定者 ) 寄りのプラクティスから。</p>

運用</h2>
運用寄りのプラクティス。</p>

それでも発生した問題</h2>
上記のようなルールを策定しても、問題が発生する事はあります。
具体的例を示します。</p>

まとめ</h2>
権限まわりザルな設定するのはホント止めた方がよいと思う。</p>

監査を行う</h3>
オラクルにはログインの試行や作業内容を監査するための仕組みが存在します。
監査が無効な場合には、必要十分な監査が行えるように監査を有効にしましょう。</p>

PUBLIC に注意する</h3>
PUBLIC に権限を付与すると、誰でもその権限を使用できるようになります。</p>
[第22回] PUBLICに注意</a></p>

インターフェース名</h3>
クラス名と同じ。</p>

実装クラス名</h3>
特にインターフェースと区別する必要があるのであれば、最後に Impl を付与する。</p>

ループカウンタ</h3>
スコープが狭いループカウンタには、`i</code>, j</code>, k</code> を用いる</p>`