Name</th>	Type</th>	Port (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> The settings when creating each repository are as follows.</p> docker-private</h4> Create it as `docker (hosted)</code>.</li>` `Check HTTP and specify the port number (5001</code>).</li>` Check Enable Docker V1 API:</code>.</li> </ul> docker-hub</h4> Create it as docker (proxy)</code>.</li> Specify https://registry-1.docker.io</code> for Remote storage:</code>.</li> Select User Docker Hub</code> for Docker Index:</code>.</li> Check Enable Docker V1 API:</code>.</li> </ul> docker-group</h4> Create it as docker (group)</code>.</li> Check HTTP and specify the port number (5000</code>).</li> Add the two repositories created above to Member repositories:</code>.</li> Check Enable Docker V1 API:</code>.</li> </ul> In my environment, I could not push unless Enable Docker V1 API:</code> was checked.</p> </blockquote> Additional Firewall Configuration</h3> After creating the repositories, allow 5000/tcp</code> and 5001/tcp</code> on the host where NXRM is installed.</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> Installation Procedure (Client)</h2> Set up the Docker environment.</p> A configuration is required to connect to a repository that does not use TLS.</p> Environment</h3> I confirmed this procedure with the following environment.</p> OS: CentOS 8</li> Docker: 19.03.8</li> </ul> Connectivity Check</h3> When sending a request to NXRM with curl, if it returns a response saying that it is not a Docker request, it is 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> Configure daemon.json</h3> Create daemon.json</code> and configure Docker.</p> vi</span> /etc/docker/daemon.json </span></code></pre> When using a repository that does not use TLS, it must be specified in insecure-registries</code>.</p> It is also possible to specify this every time on the command line, but it is troublesome, so I recommend configuring the Docker daemon.</p> </blockquote> Add the registries created in NXRM to insecure-registries</code>.</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> The configuration when also using the mirror setting is described below.</p> </blockquote> After creating daemon.json</code>, restart the Docker daemon.</p> systemctl</span> restart docker </span></code></pre> Registering (Pushing) Docker Images</h2> Log in to NXRM</h3> Specify an NXRM user for the username and password.</p> docker</span> login nexus_hostname:5000 </span>docker</span> login nexus_hostname:5001 </span></code></pre> You will be asked to enter a username and password. Log in with your own account.</p> A WARNING will be displayed when running the command, but if Login Succeeded</code> is displayed, the login was successful.</p> The authentication information is recorded in ~/.docker/config.json</code> after running the command.</p> </blockquote> Push</h3> Push the image to the hosted repository.</p> docker</span> tag image_name:version nexus_hostname:5001/image_name:version </span>docker</span> push nexus_hostname:5001/library/image_name:version </span></code></pre> For some reason, if I did not add library</code>, I got a 404 (NOT FOUND) when pulling.</p> I think it may be necessary to use a tag such as accountname/imagename:version</code>, in the same way as Docker Hub. Official images do not have the account name part, but in this kind of tagging, they seem to be under library</code>. In fact, when I downloaded the official MariaDB image and checked it in the proxy repository, its name was library/mariadb</code>.</p> </blockquote> Pull</h3> Check whether the pushed image can be retrieved.</p> The destination is not the hosted repository that was registered above, but the group repository that combines the hosted and proxy repositories.</p> docker</span> pull nexus_hostname:5000/image_name:version </span></code></pre> Mirror Configuration</h2> With the configuration so far, it is possible to register (push) and retrieve (pull) Docker images that were created by ourselves from the repository server.</p> However, with this configuration, our own images and external images (hosted on Docker Hub) cannot be handled transparently.</p> Change the configuration so that they can be handled transparently.</p> Specifically, even when retrieving an image hosted by ourselves, it should be possible to retrieve it without specifying repository-server:port</code>, as follows.</p> When pushing, repository-server:port</code> must be specified.</p> </blockquote> docker</span> pull image_name:version </span></code></pre> Docker can be configured to use registry-mirrors</code> as a Docker Hub mirror, so it should be possible to solve this by configuring the group repository we created as the mirror.</p> However, there is a problem where authentication information is not correctly passed to the mirror site, so some additional configuration is necessary.</p> Reference: registry-mirrorsが機能しない</a></p> As a solution, I use the method described in Docker is not passing auth informations when pulling from a mirror registry #30880</a>, where the authentication information is overwritten on the Nginx (proxy) side and the request is sent to Nexus.</p> Edit the nginx Configuration</h3> I finally used the following configuration.</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> When accessing a repository, the URL starts with /v1</code> or /v2</code>, so in this case the request is forwarded to the group repository. At this time, authentication information is set using proxy_set_header Authorization ...</code>.</p> The Basic Authentication value to set in $authorization</code> can be generated as follows.</p> echo </span>-n </span>'</span>username:password</span>' \| </span>base64 </span></code></pre> The above configuration also outputs upstreamlog</code> so that the actual forwarding destination can be checked.</p> I noticed the problem where pulling did not work unless I added library</code> when pushing by checking this log. If an image can be pushed but cannot be pulled and a 404 occurs, the URL that the Docker client uses to retrieve the manifests may be different from the location where the image was pushed. In this case, checking upstreamlog</code> may help solve the problem.</p> Restart nginx</h3> Check that there are no problems with the configuration:</p> nginx -t </span></code></pre> If there are no problems, restart it.</p> systemctl</span> restart nginx </span></code></pre> Client-side Configuration</h3> Change /etc/docker/daemon.json</code> as follows. Specify the Nexus host in registry-mirrors</code> and insecure-registries</code>.</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> Troubleshooting</h2> The mirror configuration was the most difficult part for me.</p> When a problem occurs, I recommend checking the following.</p> Docker (client-side) logs In my environment, they were output to syslog (/var/log/messages/</code>).</li> Nexus Repository Manager logs The output directory is /opt/sonatype-work/nexus3/log</code>.</li> nginx logs If you are using a proxy, also use the upstreamlog</code> described above.</li> </ul> Incorrect Request Destination</h3> When I pushed an image without adding library</code>, it was pushed to the hosted repository with the following structure:</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> After configuring the mirror, when I ran docker pull image_name</code>, the following error was output in the Docker log:</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> I found that it was accessing /v2/library/image_name/...</code>. (In fact, I noticed this from upstreamlog</code> before checking the Docker log.)</p> After pushing the image again as follows, I confirmed that it could be pulled.</p> docker</span> push nexus_hostname:5001/library/image_name:latest </span></code></pre> docker</span> pull image_name </span></code></pre> References</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> Wedding Dress 2026-09-22T00:00:00+00:00 Why did I make it?</h2> My late wife (a graduate of SVA in NYC who passed away young from lung adenocarcinoma) apparently wanted to wear a dress she had imagined for our wedding, so I made one that was as close to her vision as possible. :D</p> Her image was that of a fairy. It was quite different from an ordinary wedding dress, with a single piece of fabric softly spreading out from the chest. In the front, the fabric curled inward just above the knees, while in the back, the drape flowed naturally like a conventional wedding dress.</p> We looked at quite a few dresses while shopping for one, but there was nothing that matched her vision. So I decided to make one myself...</p> Material Procurement</h2> I went looking for fabric in Nippori Textile Town and eventually found what I needed at Tomato, a fabric store there.</p> The dress wouldn't have the right shape without a petticoat, so I made that too. (I remember the petticoat actually took longer to make.)</p> </p> </p> Later, one of my wife's friends said, "I'd love to wear it!" and my wife generously gave the dress to her.</p> Leather Body Bag 2026-09-21T00:00:00+00:00 I made this body bag after the body bag I received from my late wife became worn out. The main part of the original bag had become badly worn, but the belt was still in good condition, so I reused the belt. I happened to find some nice Japanese leather at Hands Shinjuku during a leather fair featuring leather from Japanese tanneries, so I used it for this bag.</p> I used black leather for the bottom part, with a separate piece for the transition. The leather parts were hand-stitched. The inner bag was sewn with a sewing machine.</p> </p> Nudibranch Pottery 2026-09-20T00:00:00+00:00 Inspiration</h2> My late wife (a graduate of SVA in NYC, who passed away at a young age from lung adenocarcinoma) practiced pottery painting. I also once made several ceramic figures by shaping pottery clay.</p> Nudibranchs.</p> I made these around the time I came across a book of nudibranch photographs and was fascinated by their beauty.</p> </p> </p> What Happened Afterwards</h2> They were displayed at my wife's pottery exhibitions and other shows, but before I knew it, they had all disappeared.</p> Maybe they're still with the people who bought them.</p>

mosaos

Modifying a Speaker Protection Board

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

Speaker Protection Board</h2>
While browsing AliExpress, I found something called an audio speaker protection board, so I decided to give it a try.

This one is rated for AC 12-16V. It is sold as a kit rather than assembled (although assembled versions are also available).
There were quite a few similar products, but I chose one with a reasonable number of reviews (see Aliexpress Link</a>).
I bought two, and both arrived safely.
I have a DIY digital amplifier, so I was thinking about incorporating this into it. However, as mentioned above, this board is designed for AC (alternating current) 12V-16V.
I expected that it would not work as-is, so I bought it with the intention of modifying it.
Here is the board.

From the board and the photos of the completed product, I was able to determine the following first.

There is a bridge rectifier to convert the AC input to DC (marked `A1</code> on the board). Digital amplifiers and similar devices use DC (direct current), so this is not necessary.</li>`
There is a three-terminal regulator after the bridge rectifier (marked L7812CV</code> on the board). This converts the rectified voltage from AC 12-16V to 12V DC. A digital amplifier that operates at 12V DC or less does not need this either. ※ Since ACV × √2</code> is the theoretical value, AC 12V becomes approximately DC 17V. Due to the voltage drop across the diodes, the actual voltage is around 15V.</li> </ul> Therefore, I expected that the board should work with a DC-powered amplifier if these parts were bypassed. * It is also possible to input DC 12V before the bridge rectifier. However, due to the voltage drop caused by the bridge rectifier and three-terminal regulator, the voltage supplied to the circuit itself would be around 9V, which would likely cause the relay to operate unreliably. I also decided to convert it to DC 5V so that I could use it with the PAM8406 I had on hand. This required the following modifications as well.
Replace the relay
Since the voltage supplied to the circuit will change from DC 12V to DC 5V, the relay needs to be replaced. The board comes with an `SRD-12VDC-SL-C</code>, so I replaced it with an SRD-05VDC-SL-C</code>. I bought SRD-05VDC-SL-C 5PIN, 5PCS</code> (see``Aliexpress Link</a>).</li>`
Change the resistor value so that the 5V relay can operate The circuit will be supplied with DC 5V instead of DC 12V. As can be seen from the product page for the relay above, the required current (coil current) is as follows: 5V: 72 mA</li> 12V: 30 mA Since the voltage also drops from 12V to 5V, the relay would most likely not respond at all if the resistor were left unchanged.</li> </ul> </li> </ul> Modification</h2> First, here is a photo of the board after applying the modifications described above. At this point, there are three modification areas (Section 1 - Section 3). Section 1</h3> Do not install either A1</code> or L7812CV</code>.</li> The terminal that was originally connected to the AC</code> section was instead connected to the output side of A1</code> (where +</code> and -</code> are printed).</li> As you can see from the PCB traces, this alone would not supply +</code> to the circuit, so short both ends of L7812CV</code> with a jumper wire. Be careful not to touch the center pad and cause a short circuit. I used an insulated wire rather than a cut-off component lead.</li> </ul> With this modification, the DC supplied to the terminal goes directly into the circuit. Section 2</h3> This is the part mentioned above: changing the resistor value so that the 5V relay can operate. The board originally has a 100K</code> resistor here. When I asked an AI about this, it told me that "shorting this part will make the relay respond," but that will kill the transistor, so don't do that lol. Section 3</h3> Replace the relay from SRD-12VDC-SL-C</code> with SRD-05VDC-SL-C</code>. Section 4</h3> I had not noticed this at this point. (Described later.) Testing</h2> I have a modified USB cable made from a USB cable I bought at a 100-yen shop (one that had already suffered a broken wire or something), so I connected it to the terminal and then to a mobile battery for testing. At this point, I tried the following for Section 2. First, I tested it with 10K. The relay operated with a "click" in less than one second.</li> I changed it to 47K. It sometimes operated, but it was unstable. The delay increased to a little over two seconds.</li> I wanted to use 33K, but I did not have one, so I connected two 68K resistors in parallel (= 34K). The delay was a little over one second, and the operation was stable, so I settled on this.</li> </ol> I confirmed that the relay responds with a DC 5V input. Connecting the amplifier</h3> I connected the PAM8406 and checked whether it would actually work. Looking at the traces on the back of this board makes it immediately obvious, but the speaker GND is shared. Many digital amplifiers, including the PAM8406, use a BTL connection. Unlike a single-ended amplifier, L-/R- (which have a voltage in the opposite phase to the + output) are not GND. They must not be shorted together. Connecting the negative outputs from the amplifier (L-/R-) to this board can, in the worst case, destroy the amplifier, so absolutely do not connect them. So what should you do? Connect L+/R+ to L/R on this board (the side that is not shorted together on the back of the board).</li> Connect L-/R- directly to the speakers without passing them through this board.</li> </ul> I connected the PAM8406 while paying attention to the short-circuit issue described above, but, as it turned out, it did not work at all lol. In fact, this board is not just a delay relay. As the "DC protection" in the product description indicates (something I noticed again later lol), it also detects DC flowing to the speakers and prevents the relay from operating when DC leakage is detected. For such an inexpensive circuit, it was actually quite well designed. The PCB traces already show that it is not designed for BTL operation = it is intended for single-ended amplifiers. In that case, the DC protection does not cause any problems. With BTL, however, voltage is applied to both the + and - outputs, so the DC protection was triggered and the relay would not turn on. That was the reason it did not work. * With VDD = 5V, both OUT+ and OUT- have approximately 2.5V (slightly less) of DC voltage even when there is no signal. One possible approach would be to change the resistor connected to the DC protection circuit (Section 4) so that the DC protection does not activate even when the PAM8406 produces 2.5V. However, that seemed like a hassle (and, after all, I bought this board because I wanted a delay relay to prevent pop noise), so I dealt with it by removing the resistor in Section 4. The DC protection will no longer work, but if preventing pop noise at startup is sufficient for your requirements, this modification does the job. In the end, the amplifier became something like this: PAM8406</li> Bluetooth (v5) support Compatible boards are available cheaply.</li> The speaker protection board used in this modification All of the above are supplied with 5V from a USB-C connector (split in parallel).</li> Two audio inputs: a 3.5mm stereo phone jack and Bluetooth They are switched using a 2-circuit, 2-position toggle switch. (The GND of the audio input does not need to be switched and can be shared.)</li> The speakers are also connected using a 3.5mm phone jack. I used a Takachi YM-10 (YM10-3-7) aluminum enclosure to keep the unit compact, so a speaker terminal would have been difficult to fit. I am also using the YM series in a somewhat unusual way, rather than its typical use with the silver side as the front.</li> </ul> Originally, my child had an AG03, but there was no way to drive the passive speakers I had on hand, so I made this amplifier. Bluetooth was not a requirement, but considering that it might also be used as a standalone amplifier, being able to play audio from a smartphone or similar device via Bluetooth makes it more versatile. </blockquote> Here is a photo. I used YAMORI GRIP (extra-strong double-sided gel tape), which can be bought at 100-yen shops and elsewhere, to secure the boards. I protected the terminals with masking tape so that they would not touch the case. * YAMORI GRIP itself is quite thick (2 mm), so that alone is probably enough in many cases. However, when using a metal case, I think it is better to take some precautions just in case. </blockquote> Other Digital Amplifiers</h2> I also have a TA2020 (based on an NFJ board), so I will probably make a version that keeps the DC 12V supply at some point. In that case, only Section 1 and Section 4 need to be modified. There are also other digital amplifiers such as the PAM8403, which is said to have more noticeable pop noise than the PAM8406. Therefore, if you want to reduce pop noise on a digital amplifier at relatively low cost, the modifications described in this article may also be useful. Since this involves modifying electronic hardware, please try it at your own risk.

Zola daisyUI blog

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

Introduction</h2>
I created a blog template using Zola + daisyUI, so I am writing this article as a reminder for myself as well.
This article describes why I created it, the setup procedure, and so on.

Why did I create it?</h2>
I had been thinking about sharing personal information through GitHub Pages for some time, but I finally got around to building the application.
mosaos/zola-daisyui-blog</a>
* An actual example can be found here.
At first, I tried implementing a simple version with React/TypeScript (I had already made it possible to display Markdown), and I also tried using Astro based on AI advice. In the end, I settled on the following technology stack.

Zola
An SSG (Static Site Generator) written in Rust</li>
daisyUI
A component library for Tailwind CSS</li>
GitHub Pages
A requirement from the beginning</li> </ul>
The reason I stopped using Node.js was simply that I did not want to end up in a maintenance hell.
I work on React projects in my professional work as well, but Node.js-based projects tend to have:

Many related packages</li>
A lot of security (vulnerability) fixes</li>
Many breaking changes</li> </ul>
The fact that I am particularly bothered by breaking changes may also be because Java (such as Spring Boot) is my strongest language. Having to perform maintenance even though the actual application itself has not changed is one thing when doing it for work, but it is a hassle for a personal information-sharing site.
For these reasons, I ended up with the configuration above.
Some people may say that daisyUI also requires Node.js, but if you use something like the full.css</code> published via CDN, you can use Tailwind / daisyUI without a Tailwind/daisyUI build process. (It includes everything, though.)
There may also be arguments about optimization, but avoiding maintenance hell is the most important requirement for me, so using resources from a CDN is perfectly fine.
Features</h2> This is the template I created. See README.md</code> for details, but it has the following features. Most of these are essentially characteristics of Zola/daisyUI and so on. Responsive Design A simple and easy-to-use layout that also supports mobile devices, powered by daisyUI and Tailwind CSS.</li> Markdown-based Blog posts and portfolio works can be easily created using Markdown. Articles can also display a Table of Contents (TOC).</li> Multilingual Support A multilingual switcher is included by default. It can be extended to any number of languages as needed.</li> Static Site Generation (SSG) Fast and secure, with no need for server-side runtimes such as Node.js.</li> Dev Containers Support The development environment can be set up quickly, reducing the effort required for environment setup.</li> Tag Support Content can be organized and categorized using tags.</li> Image Carousel / Slideshow A carousel is included for displaying multiple photos or images, such as portfolio works.</li> </ul> Development Environment</h2> I have tested it with the following environment. Windows 11</li> WSL2 (Ubuntu)</li> docker-ce Used when using Dev Containers. This is not Docker Desktop, so it can also be used in companies that do not have a Docker Desktop license.</li> VS Code</li> </ul> Setup</h2> The application part is registered on GitHub as a template project. The recommended procedure is as follows. Since symbolic links are used to check the site locally, WSL2 is recommended (when using Windows). I don't know about Mac. Creating the Repositories</h3> Access mosaos/zola-daisyui-blog</a>.</li> Click Use this template</code> > Create a new repository</code> and create it as your own repository (such as my-portfolio</code>). Private</code> is also fine.</li> Create a separate repository for the content, such as my-portfolio-content</code>. Private</code> is fine. This separates the application and content so that the application part can be updated more easily if it is updated in the future. If you do not want the extra hassle, you can also keep everything in my-portfolio</code> from step 2 without separating the content.</li> Create a repository for GitHub Pages (Public</code>). If you want to publish the site directly under the domain, use username.github.io</code> as the repository name.</li> </ol> Check the Site Locally First</h3> If you did not separate the content repository, you do not need to replace it with a symbolic link. </blockquote> Without Dev Containers</h4> Create a symbolic link from the application-side content</code> directory to the content repository. Delete the content</code> directory on the application side (my-portfolio</code>): cd /path/to/my-portfolio rm -rf content </code></pre> Create a symbolic link to the content repository (my-portfolio-content</code>). The following assumes that my-portfolio</code> and my-portfolio-content</code> are in the same directory. ln -s ../my-portfolio-content content </code></pre> With Dev Containers</h4> Symbolic links do not work here, so mount the directory instead. Do not delete the content</code> directory in my-portfolio</code>; just remove its contents. Add the following mounts</code> definition to devcontainer.json</code> in my-portfolio</code>. "forwardPorts": [ 1111 ], // Bind-mount the content repository on the host to the Zola content directory in the container "mounts": [ { "source": "${localWorkspaceFolder}/../my-portfolio-content", "target": "${containerWorkspaceFolder}/content", "type": "bind" } ] // "remoteUser": "root" </code></pre> After configuring this, run Rebuild Container</code>. If the contents of content</code> are visible (linked) from the Dev Container, the setup was successful. Check the Site</h4> Check the site locally. cd /path/to/my-portfolio </code></pre> If you are using a Dev Container, open VS Code and check from the Dev Container terminal. Otherwise, you can check it using Zola installed on WSL2 (Ubuntu). code . </code></pre> zola serve --interface 0.0.0.0 --port 1111 --base-url / </code></pre> In VS Code, a dialog saying Your application running on port 1111 is available. See all forwarded ports</code> will appear. Click Open in Browser</code>, and if the site is displayed, everything is OK. If you are not using VS Code, open http://localhost:1111/ and check that the site is displayed. Adjust .gitignore</code></h3> Once you have confirmed that it works, exclude the contents of the content</code> directory on the my-portfolio</code> side so that the files in my-portfolio-content</code> are not managed in multiple places. Add the following: content/** </code></pre> You may also want to run the following in my-portfolio</code>: git rm --cached -r content </code></pre> At this point, the local development/checking environment is ready. You can now add content or customize the application part as needed. Prepare a PAT (GitHub Personal Access Token)</h3> From here, the setup is for publishing the site to GitHub Pages using GitHub Actions. This is not necessary if you plan to generate the SSG site manually using Zola locally/in a Dev Container and publish the generated pages yourself. my-portfolio</code> needs access to the separate private repository (my-portfolio-content</code>) and the public repository (username.github.io</code>). Prepare a PAT using the following procedure. Open Tokens (classic)</code> from Settings</code> > Developer settings</code> > Personal access tokens</code>, using your account icon on the upper right. </li> Click Generate new token (classic)</code>. </li> Enter a description in Note</code> (such as portfolio deploy token</code>) and set the expiration date. Recommended: From a security perspective, 30 days</code> or 60 days</code> (regular renewal is required)</li> Compromise for personal use: If you want to reduce the effort of renewing it, 90 days</code> (a reminder email will be sent shortly before expiration)</li> </ul> No expiration</code> is not recommended because the risk is high if the token is leaked. </li> Under Select scopes</code>, check: repo</li> </ul> </li> Click Generate token</code> at the bottom of the page and keep the generated token somewhere safe. (It cannot be displayed again once you close the page.) </li> </ol> Register the Token in GitHub Secrets</h3> Register the issued token as a secret in the application-side repository (my-portfolio</code>). Open your my-portfolio</code> repository page. </li> Go to Settings</code> > Secrets and variables</code> > Actions</code>. </li> Click New repository secret</code>. Name: GH_PAT</code> (or another easy-to-understand name)</li> Secret: Paste the PAT string you copied earlier.</li> </ul> </li> Click Add secret</code> to save it. </li> </ol> Create the GitHub Actions Workflow</h3> Create a GitHub Actions configuration file in the root of the application-side repository (my-portfolio</code>). This configuration is based on the author's setup, so change it as appropriate. .github/workflows/deploy.yml</h4> name: Build and Deploy Zola Site on: push: branches: - main # use master instead if your repository uses master jobs: build-and-deploy: runs-on: ubuntu-latest steps: # 1. Check out the application repository - name: Checkout my-portfolio uses: actions/checkout@v4 # 2. Check out the content repository (Private) directly into the content/ directory - name: Checkout my-portfolio-content uses: actions/checkout@v4 with: repository: mosaos/my-portfolio-content # username/content repository name token: ${{ secrets.GH_PAT }} path: content # 3. Install Zola - name: Setup Zola uses: taiki-e/install-action@v2 with: tool: zola@0.17.2 # Match the version used in the development environment # 4. Build the site with Zola - name: Build Zola site run: zola build # 5. Push the build output (public/) to the mosaos.github.io repository - 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" # Move to the public directory containing the build output cd public # Initialize it as a Git repository and push 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> After creating the configuration file, commit and push it. Before committing/pushing, change base_url</code> in config.yml</code> to the URL of your own GitHub Pages site. If the Action runs successfully, everything is OK. At this point, if content</code> has not been registered yet, the Action will fail, but after registering content</code>, rerun it and make sure it completes successfully. GitHub Pages Settings on the Deployment Destination (username.github.io</code>)</h3> Open Settings</code> > Pages</code> in the username.github.io</code> repository.</li> Configure Build and deployment</code>: Source</code>: Select Deploy from a branch</code>.</li> Branch</code>: Select main</code> (or master</code>) and /</code> (root) as the folder, then click Save</code>.</li> </ul> </li> </ol> Triggering a Build When content</code> Is Updated</h2> With the configuration above, an update to my-portfolio</code> (a push to main</code>) triggers Actions. Normally, it is more convenient for the site to be updated when content</code> is updated. In this case, add the following configuration to both the application-side (my-portfolio</code>) and content-side (my-portfolio-content</code>) repositories. Application Side (my-portfolio</code>)</h3> Modify the on:</code> section of .github/workflows/deploy.yml</code> on the application side so that it can wait for a signal (repository_dispatch</code>) from the content side. .github/workflows/deploy.yml</h4> Add the following near the beginning. Register the GH_PAT</code> secret in the same way as you did for the application-side repository. name: Build and Deploy Zola Site on: push: branches: - main # or master # Add a setting to receive events from an external repository (the content repository) repository_dispatch: types: [content_updated] jobs: build-and-deploy: runs-on: ubuntu-latest # ( the rest is omitted ) </code></pre> Content Side (my-portfolio-content</code>)</h3> .github/workflows/deploy.yml</h3> Create a new configuration file. name: Trigger App Build on Content Push on: push: branches: - main # Match the main branch used to manage articles (Markdown) jobs: trigger_dispatch: runs-on: ubuntu-latest steps: - name: Repository Dispatch uses: peter-evans/repository-dispatch@v3 with: token: ${{ secrets.GH_PAT }} # Register the same GH_PAT as a Secret on the content side repository: mosaos/my-portfolio # Target application-side repository event-type: content_updated # Must exactly match the name configured in types on the application side (be careful with hyphens) </code></pre> Keeping Up with Updates to zola-daisyui-blog</h2> Register the Upstream Repository</h3> A repository created with Use this template</code> is completely independent of the original repository, unlike a Fork. If you want to keep your repository up to date with changes to the original template repository, set this up first. Move to the root of the project you created: cd my-portfolio </code></pre> Add the upstream repository: git remote add upstream https://github.com/mosaos/zola-daisyui-blog </code></pre> You can check whether it was registered correctly with: git remote -v </code></pre> Apply Changes from the Original Template</h3> First, fetch the changes: git fetch upstream </code></pre> With a normal merge, Git may consider the histories unrelated, so merge with --allow-unrelated-histories</code>. git merge upstream/main --allow-unrelated-histories </code></pre> The changes from the original template will be merged. If there are conflicts between the parts you modified and the template updates, resolve them. Once the conflicts have been resolved, commit the changes. Finally, push them to your own repository and you are done.
About Me 2026-09-22T00:00:00+00:00 Profile</h2> Name: mosaos</li> Occupation: Senior Engineer / System Architect / Tech Lead / Instructor</li> Areas of Activity: Covers a wide range of areas, from low-level technologies (physical control, KVM, and infrastructure) to web application development, facilitation of large-scale projects, and organizational education.</li> </ul> Technical Summary</h2> 【An Architect Who Can Complete Everything from Physical Control and Databases to Facilitation of Large-Scale Projects】 Outstanding problem-solving ability and risk management: During a period of rapid service growth, I responded to a critical database load problem by quickly conducting a PoC and proceeding with an online table type change. Even when design problems were discovered just before a release, I presented a realistic improvement roadmap that prioritized business impact and led the project to success.</li> Facilitation for organizing chaotic situations: In meetings where coordination between stakeholders was difficult, I used a whiteboard to visualize the issues and identify their essential points. I solved complex coordination issues in a simple way and received high evaluations from experts.</li> Architecture design and performance optimization: Rather than staying at the theoretical level, I cover a wide range from low-level technologies to web development, including building high-performance REST APIs with Seasar2 + JAX-RS (Jersey) and implementing video filters in C++.</li> Specialist in practical, hands-on education: I have trained a total of several hundred engineers for practical work through an original curriculum that emphasizes active recall.</li> FinOps & DevOps: Cost optimization through AWS CUR visualization, as well as building DevOps environments (GitLab-CI/Sentry, etc.) on a self-built KVM platform.</li> </ul> Main Career</h2> Current: Working at a company in Tokyo, engaged in application development and management of an engineering group, as well as promoting and leading internal study sessions and virtualization</li> </ul>
Best Practices for cron

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

An issue occurred when temporarily stopping cron, which led to a discussion in a certain place about things such as change management. This is an overview of my best practices for cron.
* For now, I have just written down what I was thinking and what came to mind while listening to the discussion, so I may remember other things later or realize that "this was actually wrong after all."
* These are my personal cron tips, so feel free to customize them or optimize them for each project.
* This is a rewrite of an old article, so some parts may differ from the current environment.
Development</h2>
First, some practices from the development side (cron implementers/configurators).
Use /etc/cron.d</h3>
Assuming that it is supported by the environment you are using, use /etc/cron.d/</code> if possible. * Do not edit crontab directly with crontab -e</code>.
Specifically, place multiple crontab configuration files under /etc/cron.d/</code>.
ls /etc/cron.d/ system-a system-b </code></pre> Example of 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> This provides the following benefits:

crontab settings can be grouped in a meaningful way.</li>
By assigning appropriate permissions to individual configurations, it is also possible to prevent unnecessary modification of crontab settings for other systems.</li>
It works better when version-controlling them, just like cron shell scripts (described below).</li> </ul>
Allowing individual users to have their own cron settings (users editing them with crontab -e</code>) is also OK, but in many cases, I think there are relatively few use cases where individual users need to use cron.
Use shell scripts to execute tasks</h3> For simple commands or processes that can be executed with a one-liner, it is possible to directly specify system or middleware commands in crontab. However, when executing tasks managed by an organization, I recommend always creating a shell script to execute the task and implementing the processing in that file. Then, specify the shell script to be executed in crontab. This provides the following benefits:The handling of environment variables differs when cron runs a command from when a user logs in, which can sometimes cause problems. By using a shell script, it becomes easy to set the environment variables required before executing commands, or to change them when necessary.</li> By version-controlling the shell script itself, it becomes possible to track the history of changes to the processing, and to perform appropriate reviews by going through a PR/MR process.</li> It also becomes easy to call another script for common processing (such as setting environment variables, notifications, or logging) from the script specified in cron before calling the actual processing.</li> </ul> Establish coding rules for scripts</h3> I don't think it is necessary to make the rules too strict, but it is better to unify the level of description and processing as much as possible, for example by preparing an easy-to-understand template. Write comments at an appropriate level of detail.</li> Turn values that may change into variables.</li> Define common processing and use it. For example, make it a common script and call it.</li> </ul> Use version control</h3> The reasons for using version control include, of course, being able to restore the previous version or check differences when a problem occurs. However, the following points should also be aimed for. Deployment using CI/CD At present, I think the number of projects that use CI/CD for application deployment is increasing, but Linux scripts, cron configurations, and so on should also be managed using a version control system and deployed using CI/CD. This is also related to concepts proposed by The Twelve Factor App</a>. </li> Reviews using PR/MR When an incident occurs related to a release or change, I feel like I have heard the following kinds of explanations many times: One person did the work.</li> There was no checking process, or it was not functioning.</li> No review was performed.</li> </ul> And then, as a countermeasure: "We will make sure to do it properly from now on." However, with this kind of countermeasure, even if you only put up a slogan, things often return to the way they were after a while. It is more effective to use the power of systems/tools by always using PR/MR (Pull Request/Merge Request) so that checks are always performed. </li> </ul> * GitLab should also allow you to restrict permissions for pushing. If you are going to require MRs, restrict direct pushes to designated branches, for example. Use tools to enforce the rules rather than relying on slogans. Prevent multiple executions</h3> When implementing an application, it is possible to use mechanisms provided by the processing language (such as Java) to prevent multiple executions. However, multiple executions can also be prevented by using flock</code>, a standard Linux tool. */5 * * * * appuser flock -n /var/lock/cron-task.lock cron-task </code></pre> Here is an actual example. Script</h4> Create a script containing the processing. Create /root/scripts/sleep.sh</code> as follows. #!/bin/bash INTERVAL=300 sleep $INTERVAL echo "$INTERVAL sec slept" </code></pre> It simply sleeps for the number of seconds specified by the interval and then outputs a message with echo</code>. It is configured so that the job continues for 300 seconds (5 minutes). cron configuration</h4> For the cron configuration, create /etc/cron.d/test</code>. # put some comment here * * * * * root flock -n /var/lock/cron-test-sleep.lock /root/scripts/sleep.sh </code></pre> flock</code> prevents multiple executions. It runs at one-minute intervals. Execution result</h4> Output from /var/log/cron</code>: 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> The cron job runs at one-minute intervals, but you can see that the actual processing (echo</code>) occurs at five-minute intervals. Use timeouts</h3> Depending on the type of task, using a timeout can be useful. Normally, jobs executed by cron run without a time limit, but this may not always be desirable. For example, for a job that runs at regular intervals, if it does not finish within a certain amount of time, the job may be executed again while the previous execution is still running. In such cases, try using timeout</code> (/usr/bin/timeout</code>) or something similar to limit the execution time. */5 * * * * appuser timeout 10s cron-task </code></pre> As with flock</code>, here is an actual example. Script</h4> #!/bin/bash while true do date sleep 1 done </code></pre> Outputs date</code> at one-second intervals. cron configuration</h4> Edit the /etc/cron.d/test</code> file. # put some comment here * * * * * root timeout 10s /root/scripts/loop.sh </code></pre> Timeout after 10 seconds. Execution result</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> You can see that the processing is interrupted after 10 seconds. Depending on the task, terminating it midway may cause serious problems, so be careful about where you use this. Operations</h2> Operational practices. Restrict permissions</h3> When running a cron job, specify the execution user appropriately and restrict its permissions. 0 * * * * root cron-task </code></pre> The above crontab configuration specifies that it should be run as the root user. However, when it is executed as root, it can be difficult to impose restrictions, even if, for example, the execution job is something that could destroy an important part of a system directory. It is better to create a user with the minimum permissions required for each application and specify that user instead. 0 * * * * appuser cron-task </code></pre> Do not discard output</h3> */5 * * * * appuser cron-task >/dev/null 2>&1 </code></pre> Do not redirect output to /dev/null</code>. When looking at examples on the Internet and copying them as they are, there may be cases where output is discarded without really understanding why. However, this means throwing away clues that could be useful when a problem occurs, so unless there is a specific reason, do not discard the output. Other</h2> I have seen many environments where, in incident management, a ticket is closed after simply dealing with the incident without taking any measures to prevent it from happening again. In such environments, problems caused by simple carelessness are likely to continue occurring in the future. If similar problems occur frequently, it may be better to consider introducing a platform (job management tool) that makes this kind of problem less likely to occur. </li> If commercial management tools are expensive... open source is also an option. For example, DolphinScheduler</a>. I have never used it, but judging from the screenshots, it looks pretty good. If it really is what it claims to be, a "big data distributed workflow scheduling system," it may be usable for some time to come. </li> If containerization will be promoted in the future, use CronJob</a> in Kubernetes, for example. Keep in mind that the optimal choice may differ depending on the platform. </li> Even if there are best practices, they are meaningless if the individual developers and operations staff responsible for implementation do not follow them. Rather than handling this at the project or individual level, the company as a whole should establish a certain level of policy and roll out the best practices across the organization. </li> </ul>
Best Practices for GitLab 2026-09-22T00:00:00+00:00 The Best Practices series. My personal GitLab practices, so to speak. * This is a rewrite of an old article, so some parts may differ from the current GitLab UI. Introduction</h2> I have had both things that worked well and things that did not work well while using GitHub personally and GitLab for work. Based on these experiences, I will summarize some Tips such as: Things that may work well if you do them this way.</li> Things that may fail if you do them this way.</li> Features that may be useful if you use them.</li> </ul> * These are my personal Tips, so feel free to customize them as appropriate for each project. * I will also describe some features that are probably rarely used at workplaces. Using them may improve the quality of a project. Git</h2> Learn the basic operations yourself. If you use GitLab, you will probably use Git. * There may be cases where Issue management is not used (for example, Redmine is used for task management while GitLab is used for source management, resulting in a mix of management tools). If you are not confident about how to use Git, use methods such as the following to master the basic operations. Learn / research by yourself (books / Internet)</li> Get used to it personally using GitHub, etc.</li> Ask someone who knows it well.</li> </ul> Some companies may have few people who will teach someone from scratch when they have no idea what they are doing. If you are not confident about the operations, randomly touching and breaking a branch that is actually in operation may be something that could get you kicked out depending on the company/project. Prepare a test repository and practice. If you break the production environment without even practicing, you cannot really complain if people regard you as incompetent. It is also possible to build an environment including GitLab + GitLab Runner with docker-compose, so if you want to experiment with various things, I recommend building the environment with Docker. * I once saw someone who was not confident about how to use either Git or SVN, and people jokingly wondered whether they were really a developer (they weren't lying about their career history, were they?). Permission Management</h2> When adding members to a project, assign appropriate roles. In Best Practices for cron</a>, I wrote: * GitLab should also allow you to restrict permissions for pushing. If you are going to require MRs, restrict direct pushes to designated branches, for example. Use tools to enforce the rules rather than relying on slogans. </blockquote> When taking measures such as the above, you need to configure the settings so that merge/push to specific branches is allowed only for members with a specific role or higher. * This can be configured from [Settings</code>] > [Repository</code>] > [Protected branches</code>] in the project. However, if everyone, including members of partner companies, has Maintainer</code> permissions, appropriate restrictions cannot be enforced even if you configure the above settings. I mentioned the inability to properly restrict functionality, but this is a security problem in the first place. Maintainer permissions should be limited to employees only (preferably to a limited number of members who can make the appropriate settings), while normal developers should be assigned Developer permissions. * From an audit perspective as well, assigning unnecessary permissions without a reason is probably not acceptable. The following kind of situation is something I have seen fairly often even in companies, as is also the case with Redmine: Why does this member have this role? The permission assignment is basically a free-for-all. Giving permissions simply because they seem convenient is not a good idea. If you are doing this, fix it. Branch Strategy</h2> For projects that are already in operation, I assume there is a branch strategy for each project. If there is already a defined way of operating the project and it is working well, use it. Here is an example of a branch strategy I used in the past. * It is similar to gitflow, so if you have used gitflow before, it should be easy to understand. master</code>(or main</code>) For releases. It is deployed to the production environment. Do not edit master directly. When merging into master, create a tag. </li> develop</code> The main development branch. Created from master. </li> feature</code> A branch for each issue. Created from the latest develop. The branch name was feature/issueNNN</code> (NNN is the issue number). A separate branch is created for each issue, and after implementation is completed, it is merged into develop. * Initially, there was also an idea of creating development branches for individual members rather than creating them by function. (A member had used that approach before.) However, with this approach, one functional change could span multiple branches (for example, when different developers are responsible for the frontend and server-side), so we stopped using this method. </li> hotfix</code> Used when a critical bug occurs in master. Created from master where the critical bug occurred. The branch name is hotfix/issueNNN</code> (NNN is the issue number). After fixing the bug, it is merged into master. </li> </ul> When merging, create an MR and merge after review. * Depending on the project member structure and the contents of the MR, self-review was allowed. * The above rules work more easily when ticket-driven development is adopted as the development method (because an issue should always have been created). What should you do if you are not using ticket-driven development? Just make it ticket-driven development! (Recommended.) * By the way, I once used the feature/#NNN</code> format for branch names, but this format was discontinued because having #</code> in a branch name caused problems with links to GitLab (the link did not work from Slack notifications). It is better not to include #</code> in branch names. Creating Branches</h2> When adding a new feature or fixing a bug, create a branch according to the branch strategy</code> defined/adopted by the project. Branches can also be created on GitLab, but this has the following side effects. If you use New Branch</code> on GitLab, the created branch is committed/pushed, so CI/CD (Pipeline) is executed. It would be nice if there were a way to determine in gitlab-ci.yml whether New Branch</code> was used from GitLab, but apparently this cannot currently be determined, so CI/CD is executed just by using New Branch</code>. This is inconvenient for the following reasons: Unnecessary CI/CD runs. Various resources are wasted (computing resources, time, storage on the remote repository, etc.).</li> It is easier to discover problems in CI/CD (Pipeline) if CI/CD runs only when a feature addition, bug fix, etc. is pushed. If a Pipeline runs every time a branch is created, there is a possibility that Pipelines will no longer be checked properly.</li> </ul> </li> </ul> Based on the above, unless there is a special reason, I recommend creating branches using the following procedure. Create a branch locally from the source branch.</li> Using the created local branch, make some changes (feature addition, bug fix, etc.), then build and test it locally.</li> Commit locally.</li> Push to the remote (GitLab). For a newly created branch, the branch is created on the remote for the first time at this point, and CI/CD is executed.</li> </ol> The advantages of using the above procedure are as follows. The remote branch is not created until an actual change (local Commit) is reflected (Push). You may create a branch but ultimately not Commit/Push anything. In this case, no GitLab resources are wasted. </li> Unnecessary CI/CD does not run. When New Branch</code> is used on GitLab, CI/CD runs as described above. This means that the state of the latest commit on the branch from which the new branch was created (such as develop) is run through CI/CD again. Running CI/CD again for a Commit/Push that has already been checked by CI/CD is unnecessary. </li> The Pipeline history does not get cluttered. Related to the above, unnecessary Pipelines leave execution history that should not have been there in the first place. If a problem occurs in CI/CD and you need to investigate the past history, having a lot of this kind of history increases the investigation cost. </li> </ul> You can create branches in a development environment such as VSCode without using New Branch</code> on GitLab. Create branches using the procedure above. * Most members were creating branches using the above procedure, but at one point a situation occurred where a Pipeline was executed when some members used New Branch on GitLab. This resulted in "What is this Pipeline?", so I documented and rolled out the above procedure at the time. * Some people may say, "Our project doesn't use CI, so it doesn't matter." However, there is always a possibility that CI will be introduced in the future. Fixing a method that members have already become accustomed to can be costly (depending on the members). I think it is better to adopt a method that causes fewer problems. Commits</h2> When committing, write an appropriate commit message. When using ticket-driven development with GitLab, a commit is work corresponding to a ticket (issue) that was created beforehand, so include the issue ID in the commit message. This automatically associates the issue and commit (cross-links are created). When specifying the issue ID, use the #nnn</code> format (nnn is the issue ID (a decimal number)). Writing it at the beginning of the commit message makes it easy to understand and less likely to be forgotten. * I have seen cases where someone put a space between #</code> and nnn</code>, as in # nnn</code>, and the link was not created, so do not put a space between them. * Even when tickets themselves are managed with Redmine, it is also possible to integrate them with the Git repository by using Redmine's repository feature (additional configuration is required). Merge Requests</h2> When performing a merge, always create a merge request (MR). (Do not merge without an MR.) Click Merge requests</code> from the GitLab menu.</li> The MR list screen will be displayed, so click the New merge request</code> button.</li> Two branch input fields, Source / Target, will be displayed, so set each branch. When doing normal feature development, they will be as follows. (This differs for hotfixes and merges to master. If you are unsure, consult someone knowledgeable.)</li> </ol> Source branch</code>: the branch to be merged (feature/issueNNN</code>)</li> Target branch</code>: the branch to merge into (develop</code>)</li> </ul> Click Compare branches and continue</code>.</li> You will be taken to the New merge request screen, so first check the changes. If you scroll down the screen, the Commits</code>, Pipelines</code>, and Changes</code> tabs are displayed. Check that the following are correct. If there is a problem, stop creating the MR for the time being, resolve any problems with the branch creation procedure or file editing, and then create the MR again.</li> </ol> Commits</code> The commits included in the MR. If commits containing content different from what you are trying to merge are included, assume that there is some kind of problem.</li> Changes</code> The file differences before and after the MR are included. Check whether the differences (changes) are correct. If changes that you did not make, or incorrect changes, are included, assume that there is some kind of problem.</li> </ul> If there are no problems with Commits</code> or Changes</code>, configure the following MR contents as appropriate.</li> </ol> Title</code> Set the MR title as appropriate.</li> Description</code> It is a good idea to write an overview of the changes included in the MR.</li> Reviewer</code> If you want someone to review the MR, set that member as a reviewer. Even if you set this in GitLab, the other person may not notice it, so I recommend also notifying them that you would like a review via Slack or another means.</li> </ul> Click Create merge request</code>.</li> The member who was asked to review checks whether there are any problems with the MR and comments on the MR if necessary.</li> The MR creator explains the reviewer's comments, makes code changes, etc., and resolves the issues.</li> Repeat the 6 -> 7 process until there are no problems, then the reviewer clicks the MR's Approve</code> button.</li> The MR creator (or the member assigned to the MR) confirms that it has been Approved and clicks the Merge</code> button. By default, Delete source branch</code> is checked. If you do not want to delete the source branch (feature/issueNNN</code>, etc.) after merging because you will continue working on that branch, uncheck it before clicking the Merge</code> button.</li> </ol> This is also effective for preventing problems such as the following, which sometimes occur even in companies: One person did all the work.</li> There was no checking process, or it was not functioning.</li> No review was performed.</li> </ul> Creating Issues</h2> When creating an issue, create an appropriate issue. I wrote something similar in Best Practices for Redmine</a>, but the following points are worth paying attention to. Create it at an appropriate level of granularity.</li> Give it an appropriate title.</li> Write a necessary and sufficient description (overview).</li> Do not write multiple tasks.</li> Make the completion conditions clear.</li> Assign someone to it.</li> Set a period (an estimated period is also fine).</li> For bugs, include the necessary information such as reproduction steps, environment (browser used, etc.), version, etc. * When I was working at a certain foreign-affiliated company, I once saw someone register a bug in the BTS (bug tracking system) without writing this kind of information, and get a reply saying, "Don't write a shitty issue. Rewrite it right away." lol.</li> </ul> From here on, features that are not used very often. Labels</h2> Labels can be added to issues. Labels can be configured per Project. Using them improves the visibility of issues. * They are particularly useful when displaying a board (Kanban, described below) or a list of issues. * The background color can also be configured individually, so if labels are properly configured and used, you can eventually tell what kind of information an issue contains from the label color. They can be configured from the top icon [Project information</code>] > [Labels</code>] in the project's left menu. I use labels such as the following. For Kanban</h3> Doing</code> In progress. Color: #5CB85C</li> To Do</code> Planned. Color: #F0AD4E</li> </ul> Close-related</h3> Used to classify Closed issues. Color: #808080 Close: Fixed</code> Fixed / addressed.</li> Close: Wontfix</code> Will not be addressed.</li> Close: Duplicate</code> Duplicate.</li> Close: Invalid</code> Incorrect.</li> Close: Postponed</code> Postponed.</li> </ul> Priority-related</h3> Priority. Priority: Critical</code></li> Priority: High</code></li> Priority: Middle</code></li> Priority: Low</code></li> </ul> The priority labels can be ordered, so I set the label background colors as a gradient. From Critical onward: #ff0000, #ff4400, #ff8800, #ffbb00 Type-related</h3> Issue classification. Color: #6699dd Type: Bug</code> Bug.</li> Type: Documentation</code> Document/documentation creation.</li> Type: Feature</code> Feature addition/extension.</li> Type: Refactoring</code> Refactoring.</li> Type: Review</code> Review.</li> Type: Test</code></li> </ul> Even if the issue list or Kanban simply becomes colorful and makes you feel somewhat better (* personal opinion), there seem to be few disadvantages in terms of improving visibility. Also, when I configured labels, there were members who interpreted this as meaning that every issue must have a label, but that is not the case. Depending on the type of label, there may be labels that should be mandatory, but it is not necessarily possible for the issue creator to immediately determine things such as the priority. Once a label has been assigned, it may be interpreted as meaning that it has already been set and that the assigned label is appropriate. Therefore, for things that cannot be determined reliably at the time of issue creation, I think it is better not to assign a label and instead set it during a discussion or similar. * There is a feature called Scoped labels</a>, and I thought this would be useful, but it was not available in the non-PREMIUM version. This feature allows labels in key::value</code> format by putting ::</code> in the label name. This format would be more convenient when assigning labels such as Priority or Severity. Reference</h3> Labels</a></li> </ul> Milestones</h2> They can be configured/used from Issues</code> > Milestones</code>. I also use milestones in actual work projects to describe what is planned for each release, but it seems to me that there are not many projects around me that set milestones. Unless it is a contract development project where the work is simply considered finished once it is delivered, it makes the project easier to understand if you record what you are doing in the current development or what you will do up to the next release (the main purpose and major additions). You do not need to list individual issues in the milestone, but since a milestone can be set on each issue itself, it can also be used for looking back on things such as: Which milestone was this issue implemented in?</li> Which issues were addressed in a particular release (Milestone)?</li> </ul> It can also be used to indicate that although an issue has been raised, the task will not be performed in the current milestone (the request is acknowledged, but implementation has not been decided). Reference</h3> Milestones</a></li> </ul> Kanban</h2> It can be used from Issues</code> > Boards</code>. GitLab calls this "Boards", but I think many people are more familiar with the term Kanban. By default, GitLab provides the following states: Open</code> The state when an issue is created.</li> Closed</code> Move to Closed</code> when the work is completed.</li> In addition to the above, labels representing states on the Kanban board can be configured.</li> </ul> Personally, I often managed tasks using a Gantt chart in Redmine, but in some projects I also managed tasks using Kanban based on requests from the customer's manager, etc. (For Redmine, I used an Agile plugin.) We regularly checked tasks with the relevant people on the Kanban board and changed the state of each task. Everyone can see the general status of the tasks.</li> By operating it with rules such as moving important tasks higher on the board, the importance/priority of tasks can also be visualized.</li> Since the assignee is also displayed, it is easier to understand how many tasks each person is handling.</li> </ul> Whether it is suitable or not depends on the type and size of the project, the characteristics of the participating members, etc., so it is not something that must always be used. However, if you have never used it, it may be worth trying. I think it has good compatibility with situations such as: "It is too small a project to make a Gantt chart..."</li> When using an agile development methodology.</li> </ul> Reference</h3> Issue boards</a> </li> Trying Kanban and Scrum with GitLab Issue Boards</a> </li> </ul> Time Management</h2> By using Time tracking</code> and Due dates</code>, it is possible to manage task time and schedules. Time management for each task (issue) is important when progressing a project. Personally, I do not think it is necessary to manage time rigidly for a project that is progressing smoothly without needing time tracking, but if situations such as the following continue: Progress is not going well.</li> You do not know how much effort a task will require.</li> </ul> then it is better to start by making the situation visible. Problems that are not visible are very often left unresolved / not improved, so making them visible is the first step. GitLab's Time tracking</code> and Due dates</code> can be used to manage task time and schedules. For each issue, you can make the situation visible by recording: How long it is expected to take Estimate: /estimate</code></li> The actual effort spent /spend</code></li> When it is expected to be completed Due date</code></li> </ul> Estimate</h3> You can enter an estimated effort by entering something like /estimate 1w 2d 5h</code> in an issue comment. Hints are displayed while entering the command, so use them as a reference.</li> Note that 1w == 7d is not the case; 1w = 5d.</li> Obviously, 1d = 24h is not the case either, but I do not think anyone gets this wrong.</li> </ul> To cancel an estimate, use remove_estimate</code>. To change it, enter /estimate xxx</code> again. It seems to overwrite the previous value rather than adding to it, so be careful about this as well. Actual Effort</h3> Enter it using /spend xxx</code> in an issue comment. The time format is the same as estimate</code>. * With /spend, the entered value is added to the existing value (unlike /estimate). If you enter both estimate and spend, a progress bar is displayed in the Time tracking</code> section on the right side of the issue. Due Date</h3> The due date can be entered in the Due date</code> field on the right side of the issue. It is also possible to set it using /due xxx</code> in an issue comment, but examples of the format for the xxx part include in 2 days</code>, this Friday</code>, and December 31st</code>, which may be unfamiliar to Japanese users. I recommend setting it using the calendar in the Due date field. Issues that are past their due date are displayed with a different color, and their display in the To-Do List</code> (accessible from the icon in the upper-right of GitLab) also changes. Reference</h3> Time tracking</a> </li> Due dates</a> </li> </ul> Gantt Chart</h3> Apparently, this can be done with the Roadmap</a> feature with Premium or Ultimate. I have used https://github.com/lamact/react-issue-ganttchart to display a Gantt chart based on Due dates. If you want to use a Gantt chart with CE or similar, you may want to try it. * This is not a GitLab feature itself. MR Draft Feature (formerly WIP)</h2> Below the MR Title input field, there is a message saying Start the title with Draft: to prevent a merge request that is a work in progress from being merged before it's ready.</code>. By clicking the Start the title with Draft:</code> link, you can indicate that this MR is in a draft state. This feature was formerly called WIP (Work In Progress), and an MR created in Draft state is created with the merge button disabled. When work is still in progress and not yet complete, but you want reviews or comments (a draft state), you should use the MR Draft feature. If you manage documents on GitLab and want members to comment or check them, I think this can also be useful. An MR created in Draft state can also be changed to a non-Draft state using the Mark as ready</code> button after reflecting the review comments. (It can also be returned to Draft state again.) Reference</h3> Draft merge requests</a></li> </ul> Problems That Still Occurred</h2> Even if you establish rules such as the above, problems can still occur. Here are some specific examples. What Is This Issue Supposed to Do?</h3> An issue was created with only a title, or with an insufficient overview, and it ended up in a "What is this supposed to do?" state. The flow was something like this: Member B: "There is a problem with XX regarding OO, so we should address it."</li> Member A: "I'll handle it."</li> Member B: "Please write an issue."</li> Member A: "Understood."</li> Member A: Creates an issue (title only). The title itself was something like Decide OO</code>, which leaves you wondering, "Decide what?"</li> </ol> The issue then remained untouched for some time (for reasons such as other tasks having higher priority). Member A: Closes the issue because there was "nothing that needed to be decided."</li> Member B: Comments that the problem has not been resolved.</li> Member A: Admits that they do not remember anymore.</li> </ol> This problem can be avoided if the issue contains the necessary and sufficient information. * The same problem may occur repeatedly (based on experience). * If it keeps happening, it is best to have the members themselves come up with countermeasures, but if that is not possible, prepare an issue template</a>. Branch Name Does Not Follow the Naming Convention</h3> Follow the naming rules. When pushing a new branch to GitLab, I recommend checking things such as: Is the branch name appropriate?</li> What do the existing branches look like?</li> </ul> Problems with the Branch Creation Procedure (Probably)</h3> There was once a problem where an MR included changes that had already been merged. When creating the feature branch, it seems that the branch was probably created not from the latest develop, but from a local develop that had not been updated to the latest state. Even if someone accidentally proceeded to create the MR as-is, if they checked the differences before creating the MR (which can be checked on GitLab), they should have noticed that the branch contained changes they had not made in that feature branch. The reasons for this problem included the following two things: The branch creation rules were inadequate.</li> There was no review at the time of the MR. Even when there is no reviewer, you still need to check whether the differences included in the MR are appropriate. In the case of self-review, check them properly yourself.</li> </ul> Summary</h2> I really think you should stop using overly lax permission settings. Oracle User Management Best Practices 2026-09-22T00:00:00+00:00 Oracle User Management Best Practices</h1> My personal best-practice series lol. I will not cover things used individually, such as development environments, here. This is specifically about best practices for production environments (and staging environments shared by multiple people). * I am not an Oracle master, so this may contain incorrect information. Please keep that in mind. * I am writing down some best-practice-like guidelines on how access users should be managed for databases in production environments. * These ideas may also apply to permission management for applications and operating systems, not just databases. * This topic was written in the heat of the moment when someone messed something up... * This is a rewrite of an old article, so some parts may differ from the current Oracle specifications or UI. Terminology</h2> Let me define a few terms first. DBA Short for Database Administrator. A database administrator. A person/account that can do anything to the database (has all privileges).</li> Default user [第21回] Users created by default from the beginning</a></li> Production environment The production/operational environment.</li> Staging environment An environment used for verification, etc. It is used for pre-production verification and testing. Unlike individual developers' development environments, it is shared by multiple people.</li> </ul> Best Practices</h2> Grant privileges to roles, not users</h3> Oracle provides a mechanism for handling roles (ROLE), so instead of granting privileges to individual users, assign privileges to roles and configure individual users to belong to those roles. Reference: Checking / Creating / Granting / Changing / Revoking / Deleting Roles</a> Give users the minimum access privileges they need.</h3> When you want to make management less restrictive, you may be tempted to give users many privileges, but this can introduce security risks. For important systems, give users only the minimum privileges they need to perform their work. Perform auditing</h3> Oracle provides mechanisms for auditing login attempts and operations. If auditing is disabled, enable it so that sufficient auditing can be performed. Lock default users whenever possible.</h3> [第21回] Users created by default from the beginning</a> are among the easiest accounts for attackers to target, so it is preferable to lock them whenever possible. For accounts that cannot be locked, set sufficiently strong passwords. Do not make default users DBAs</h3> It is easy to make default users such as SYS/SYSTEM DBA users, but instead, create individual DBA users for the people who perform DBA operations. There are the following reasons. Auditing When a shared privileged account is used, it is troublesome to audit and track which user performed a DBA operation. Auditing is easier when individual users are provided.</li> Password management Even for DBA users, by ensuring that each person does not know anyone else's password, password management becomes easier when someone leaves the company. This is also effective from a security and auditing perspective.</li> </ul> Separate DBA and developer roles</h3> During application development, especially in development environments, the DBA and developer are often the same person. However, in production environments, DBAs and developers are usually separate. Create different roles for these two roles (jobs) and assign privileges separately. Eliminate anonymity for application/DBA users</h3> The user used by an application may inevitably become a shared/representative user. Application representative users often have powerful privileges, and even if the account information is leaked, it may be difficult to change the password. However, even after an operations staff member leaves the company, they may still be able to access the system using a password they used in the past. For applications that directly access the database and for personnel responsible for database administration and operations, it is preferable to create individual accounts in order to eliminate anonymity and enforce strict access control. Nest roles</h3> Oracle roles can be nested. I have never configured this personally, but I have seen setups such as the following: DEVELOPER</code> role for developers</li> MAINTAINER</code> role for database maintenance personnel</li> MANAGER</code> role with both DEVELOPER</code> and MAINTAINER</code> privileges</li> </ul> When the privileges of DEVELOPER</code> are updated, the MANAGER</code> role is also updated. When there are users whose jobs involve multiple tasks, nesting roles may make management more flexible and reduce management costs. Do not use the CONNECT/RESOURCE roles.</h3> Some roles such as CONNECT are built into Oracle, but these roles should not be used. Since 10g R2, the CONNECT and RESOURCE roles have been deprecated based on the principle of least privilege. Overview of Oracle CONNECT and RESOURCE Roles</a> ※ The privileges included in these roles seem to differ depending on the version, so using them without understanding them can be dangerous. Be careful with PUBLIC</h3> When privileges are granted to PUBLIC, anyone can use those privileges. [第22回] Be careful with PUBLIC</a> Determine roles based on use cases</h3> Consider the following based on actual operations. As much as possible, create and visualize an access matrix or something similar to organize the privileges. Users Who are the users that access the database? What types of users are there?</li> Privileges What privileges are required for each type of user (actor)?</li> </ul> Summary</h2> When a system is still in development, it may be difficult to decide everything, but define users and roles as much as possible. Review them at appropriate intervals, such as when adding a new application or a new feature. When a problem occurs, it is also a good opportunity to review them. References</h2> [第21回] Users created by default from the beginning</a></li> [第22回] Be careful with PUBLIC</a></li> Overview of Oracle CONNECT and RESOURCE Roles</a></li> Checking / Creating / Granting / Changing / Revoking / Deleting Roles</a></li> The Key to Secure Database Operations: How Should User Access Control Be Configured?</a></li> </ul> Redmine Best Practices 2026-09-22T00:00:00+00:00 Introduction</h2> This is not a manual-style explanation of how to use Redmine. Instead, I will write about the following points when using Redmine (or similar project management tools): Things you should pay attention to</li> Things you should stop doing (bad practices)</li> </ul> * This also includes things I have heard on Redmine Japan. * I think these ideas are also useful when using project management tools other than Redmine. What is Redmine?</h2> Redmine originally started as a tool for IT developers, but today it is a project management tool used in various fields and types of work. When someone asks me, "What is a project management tool?", I explain it as something that allows you to: "Write down things you need to do on sticky notes, and remove them when they are done" with the help of IT, and</li> in a more systematic way.</li> </ul> The sticky notes are Redmine tickets, so it basically means: Write what needs to be done in a ticket.</li> Remove it when it is done.</li> </ol> Remove tickets</h3> So, if I had to give one purpose of using Redmine, it would be: "Write tickets and remove them." * If you can make removing tickets feel good through gamification, it becomes easier for people to keep using the tool. Remove your own tickets</li> Remove other members' tickets too</li> Keep records</li> </ul> At the same time, properly record the actions taken to complete the tickets. To make tickets removable</h4> If the number of tickets that cannot be completed keeps increasing, people's motivation will not improve, and use of the tool will not be encouraged. To make tickets easier to complete, pay attention to the following: Create tickets at a manageable level of granularity Tickets that cover too wide a scope (are too large in granularity) cannot be easily completed. → Split them into child tickets (create them at a granularity that can generally be completed in a few hours to a few days).</li> Do not write multiple tasks in one ticket Even when leaving records (comments), it becomes difficult to tell which task the work was for. → As above, split them into child tickets with an appropriate level of granularity.</li> Create tickets with clear completion conditions With a ticket such as "Improve operations", it is unclear what needs to be done before it can be completed. → Create tickets that describe the actual actions that need to be performed, such as "Do XX to YY", and make the completion conditions clear.</li> </ul> Visualization</h3> Keeping records makes visualization possible. Visualization is important. Be conscious of what you want to / should visualize. If this becomes unclear, you may end up with unnecessary information or fail to capture what you actually wanted to visualize. This depends on the project, so it is difficult to say "this is the answer." Here are some examples. The following is an example for a development project. Things to do (or things that should be done) Write them in tickets (pay attention to granularity)</li> Assign someone responsible (if undecided, assign it to the project manager or whoever is responsible for making assignments)</li> Set a period (a tentative period is also fine)</li> Give it an appropriate title</li> Write a sufficient description (overview)</li> </ul> </li> Schedule By recording the period and progress percentage in tickets, they can be visualized as a Gantt chart. </li> Task status Properly write the work being done in comments. Change the status and assignee as appropriate.</li> </ul> </li> </ul> Things to Pay Attention to When Operating</h2> Do not divide settings too finely When operating Redmine, it is tempting to divide various settings into many detailed categories. However, the more finely you divide them, the more the cost of configuration, operation, and maintenance increases. I recommend not dividing them more than necessary.</li> Basically, do not directly reflect the organizational structure It may be fairly common to structure the data based on actual departments and positions at the beginning, but doing this will often fail or make management difficult.</li> </ul> A project management tool is not a tool for managing the organizational or job-position structure within a project. It is ultimately a tool for handling tasks. I recommend defining only the minimum necessary and efficient trackers, statuses, roles, and projects needed for the purpose. Start with the minimum and change/improve things as necessary. The following are some specific examples of bad practices. Do not create too many trackers</h3> A tracker is a category for tickets, so let's create a separate tracker for each type of work. → "Let's create separate ones for each type of work/department!" This is fairly common. * A Redmine tracker has the characteristics of a form (it has input fields and an approval workflow). But often, you create many trackers, only to find that they actually have the same workflow. If the input fields and workflow are the same, there is a high possibility that the same tracker can be used.</li> The more settings there are, the higher the management and maintenance costs become.</li> It becomes painful when you try to organize them later.</li> </ul> Too many input fields</h3> I said that a tracker is like a form, but it is also easy to end up with a situation where you keep adding custom fields until you no longer know what needs to be entered. There are fields that are ultimately not filled in.</li> There are fields that have become merely nominal and are not actually being used.</li> </ul> Unless you plan to use the information later for analysis or aggregation, it is often sufficient to simply write it in the ticket description field. If there are items you want people to enter (but do not need to analyze), use the Issue Templates plugin. → This also helps prevent a proliferation of trackers. * Apparently, some systems actually have around 100 input fields... hell. * I have seen trackers with both an assignee and a person responsible for handling the ticket. What is the difference? Keep statuses to the minimum necessary</h3> Making them more detailed than necessary makes things difficult to understand. → A good state is one where someone who has just joined the project can understand which status to select. Have you organized the actual workflow? Some statuses exist in actual business operations but are unnecessary in the system. Stop creating statuses when it is unclear whether they are really necessary. You can always add one when it actually becomes necessary.</li> Do you really need a status where no assignee can be assigned? → This makes it more likely that tickets will not be completed.</li> If there are multiple statuses that occupy the same position in the workflow (for example, separate ones created for different departments), consolidate them.</li> </ul> * Apparently, some systems actually have around 30 statuses... Can you really understand and keep track of that workflow? * Redmine can also be used as a Kanban board by adding a plugin, but a Kanban board with 30 statuses would be chaos... Stop subdividing roles too much</h3> "It is not good for too many people to be able to see things. Let's use roles to divide permissions in detail." → I have seen places where roles are created for each job position... PM? PMO? PL? What can each role actually do in Redmine? → Roles with clearly defined responsibilities, such as approver, reviewer, and observer, are better. * You do not need to create roles based on job positions, such as "these permissions because they are a PM" or "these permissions because they are a PL." What about workflows?</h3> There is one workflow for each combination of role × tracker. The more there are, the harder they are to manage. For workflows that are the same, try to handle them with the same tracker whenever possible. Task (no approval required)</li> Customer approval task</li> Manager approval task</li> </ul> If the workflows are the same, such trackers should be consolidated so that the same tracker can be used even when work crosses departments. This makes things easier to understand. Do not unnecessarily subdivide projects</h3> It is common to have "one project per case"... If using "Versions" is sufficient, use Versions. Redmine also makes it easy to integrate with source code. → By using appropriate plugins together, it is possible to configure a Subversion/Git repository server on the Redmine server. → I recommend associating one product/service with one project.</li> </ul> If you have a project such as "XX Service - YY Improvement", you can create a "YY Improvement" version in the "XX Service" project. This allows you to divide the roadmap for each product/service as needed. GitLab Milestones work in a similar way.</li> </ul> Structuring by organizational hierarchy is a bad idea</h3> This is common. But what if a project needs to be carried out collaboratively by multiple departments? → I recommend structuring projects by case. However, if the phases are different, consider whether the problem can be solved by using Versions instead of unnecessarily splitting the project. How should Versions be used?</h3> Basically, I use Versions to divide a project by period. It seems that some people use them to divide projects along axes other than time, but if you later need to divide something by time, you will no longer be able to divide it appropriately. Therefore, do not use this approach except for projects where such a requirement will definitely never occur. Adding too many members</h3> Was it too much trouble to think about? There are way too many members, aren't there? Basically, only add people who are actually involved in the project as members. Want to let someone view it only? → If a public project is sufficient, that is enough. Conclusion</h2> Especially when starting operations, when adding trackers, statuses, or roles, you may sometimes think: "I added all these fields! It's perfectly structured to match our company, and the workflows are reflected too. Awesome!" But you may simply have failed to analyze or abstract the actual business processes. Think about ways to make things work well with fewer settings. Having detailed settings and properly abstracting business processes are two different things. Coding Rules (Java) 2026-09-22T00:00:00+00:00 Personal coding rules I have compiled through Java development. These rules also reflect experience in product development in corporate environments. Introduction</h2> One indicator of whether code is good or not is whether it is "easy for other people to understand." Whether code is easy to understand is determined by various factors, including not only the clarity of the logic, but also formatting and the conventional use of APIs. When coding in a project consisting of multiple people, it is necessary to be conscious of whether the code is easy for others to understand as well. Prioritizing readability is also beneficial for myself when I need to maintain code that I may not have touched for a long time. This document describes coding rules and recommendations for application development projects using Java as the development language. This does not mean that "you only need to pay attention to what is written here." Please code flexibly while keeping in mind the perspective of writing code that is easy to understand. This document was created as a draft, so it is intended for reference only. It is recommended that the rules be modified as appropriate for each project and its users. Files</h2> Each public class should be placed in a file named after that class. Do not write multiple public classes in a single file.</li> A non-public class that is not used by other classes may be included in the file of the public class that uses it (as an inner class). However, inner classes should not be used in principle.</li> </ul> The file encoding should be UTF-8. File Hierarchy</h2> Follow Maven's standard directory layout. Maven has been used as a de facto standard build tool for Java for a long time, and using Maven's standard directory layout makes the project structure easy for many Java developers to understand. Naming Conventions</h2> Uppercase and Lowercase</h3> Java is case-sensitive, but do not write code that distinguishes identifiers solely by differences in uppercase and lowercase letters. Bad example) private int num; private int Num; </code></pre> Good example) private int cartNumber; private int productNumber; </code></pre> Package Names</h3> Use strings consisting of lowercase English letters separated by "." and include a name representing the application/project.</li> If the application is intended to be publicly released, basically include the domain name.</li> </ul> Example) com.mosaos.projectname</code> Class Names</h3> Use UpperCamelCase. Example) UpperCamelCase</code> Exception Class Names</h3> Use a class name ending in Exception</code>. Interface Names</h3> Follow the same naming convention as class names. Implementation Class Names</h3> If it is necessary to distinguish an implementation class from its interface, append Impl</code> to the end. Abstract Class Names</h3> If there is no suitable name, start with Abstract</code> and use a name that suggests the subclasses. Do not create abstract classes unnecessarily. Consider carefully whether an abstract class is really necessary, except when there is a clear purpose such as the Template pattern. Avoid creating abstract classes (using inheritance) for reasons such as the following: Inheritance for sharing methods It becomes difficult to modify or add functionality to common methods.</li> Common methods keep being added to the base class, eventually creating a God class.</li> </ul> </li> Inheritance for sharing member variables Member variables become difficult to modify because doing so affects derived classes.</li> </ul> </li> </ul> Constants (static final</code>)</h3> Use uppercase snake case. Example) UPPER_SNAKE_CASE</code> Method Names</h3> Use lowerCamelCase. Example) lowerCamelCase</code> For methods that perform an operation, use a name in the form of verb + object, rather than object + verb. Bad example) couponGet</code> Good example) getCoupon</code> Attribute Access</h4> For methods that retrieve attributes, use the getXxx</code> or isXxx</code> form (xxx</code> is the attribute name). Attribute Setting</h4> For methods that set attributes, use the setXxx</code> form (xxx</code> is the attribute name). English and Japanese</h3> Use English as the basic language for all identifiers. In exceptional cases where translating a term into English is difficult, romanized Japanese may also be used. However, whenever possible, create and maintain a terminology dictionary and avoid using different names for the same term. Naming Symmetry</h3> When naming things, pay attention to the following English word pairs: 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> Loop Counters</h3> Use i</code>, j</code>, and k</code> for loop counters with a narrow scope. Variables with a Narrow Scope</h3> Abbreviations may be used for variable names with a narrow scope. However, do not overuse abbreviations to the point that readability is reduced. Example) InputStream in = new BufferedInputStream(...); </code></pre> Meaningful Names</h3> As a general rule, use names whose meaning can be understood from the name itself. Bad example) copy(s1, s2); </code></pre> Good example) copy(source, destination); </code></pre> Style</h2> The coding style should follow the style of the JDK source code. It is similar to the K&R style for the C language, but the opening {</code> of a class/method definition should be written on the same line rather than on a new line. Use Checkstyle</a> to check the style and automate the process as much as possible. Comments</h3> As a general rule, write Javadoc comments for public classes and methods. </li> Write only necessary comments, and keep them concise. </li> Write comments that explain why something is done. </li> Write comments before writing the code. As you will find when you try it, one of the best ways to write good comments is to describe the processing concisely in comments before writing the code. If the processing consists of multiple steps, write each step as a separate line of comments before starting the implementation. This ensures that comments are written and also helps ensure that the implementation follows what was described in the comments. </li> Make use of TODO</code> comments. Since IDEs such as Eclipse allow TODOs to be viewed together, use TODO</code> comments to describe work that should be done later when something remains unfinished due to reasons such as waiting for another person's implementation or waiting for the specification to be finalized. When viewing the list in Eclipse, use the Tasks View</code>. In addition to TODO, the following comment tags can be used as task tags. FIXME</code>: A fix is required.</li> XXX</code>: Dangerous! It works, but it is unclear why it works.</li> </ul> There are other tags besides FIXME and XXX, but when using them in Eclipse, you need to add the comments to be used under [Settings] > [Java] > [Compiler] > [Task Tags]. </li> </ul> Imports</h3> As a general rule, do not use *</code> in import statements. Scope</h3> Set appropriate scopes for methods and fields. Instance Variables</h3> As a general rule, use private scope and write setters/getters as necessary. For simple setters/getters that only set or retrieve values, use Lombok</a> as appropriate to improve code readability and development efficiency. Use of Local Variables</h3> Except for entity classes, bean classes, and similar classes, avoid using instance variables as much as possible. In particular, when using a DI container such as the Spring Framework, certain classes may be instantiated as singletons by default. Therefore, using instance variables carelessly can result in a thread-unsafe implementation. As a result, a bug may not be detected during unit or integration testing and may only occur in actual production use. In some cases, this can lead to serious problems such as the leakage of personal information, so implement such code with care. Use of final</code></h3> Use final</code> appropriately as necessary. Classes that should not be inherited</li> Methods that should not be overridden</li> Variables whose values do not change (or should not change)</li> </ul> Comparison</h3> Use the equals</code> method when comparing objects. Using ==</code> is acceptable when you want to compare whether two references refer to the same instance. Boolean Comparison</h3> Do not compare boolean variables in conditional expressions. Bad example) if (isEmpty == true) </code></pre> Good example) if (isEmpty) </code></pre> Loops</h3> Use an enhanced for</code> loop when it can be used. Referencing Through Interfaces</h3> As a general rule, use interfaces when declaring object references. In particular, the following coding style is sometimes seen when using the Java API, but it is not a good implementation and should be avoided. Bad example) ArrayList<Entry> list = new ArrayList<Entry>(); </code></pre> Good example) List<Entry> list = new ArrayList<Entry>(); </code></pre> Numbers</h3> Use the BigDecimal</code> class appropriately when necessary. Strictly speaking, arithmetic operations using primitive types or types other than BigDecimal</code> may result in rounding errors. When exact calculations are required, such as in financial or scientific applications, BigDecimal</code> is suitable. Try-With-Resources</h3> When using classes that require resource cleanup, such as streams, use try-with-resources whenever possible. String Concatenation</h3> When performance may be a concern with string concatenation, such as when performing string concatenation inside a loop, use StringBuilder</code> (or StringBuffer</code>). Use StringBuffer</code> when thread safety is required. Use of System.out.print</code></h3> Replace it with a logging API. Except when standard output is absolutely necessary or when using it for temporary debugging purposes, do not use System.out.print</code>, System.err.print</code>, or related methods in production-level applications. It is difficult to identify where the output originated.</li> With a logging API, the source of the output can be identified more easily through log format configuration, and the output destination, log level, and other settings can be changed centrally.</li> </ul> Lambdas</h3> Lambda expressions may be used wherever they are applicable. Stream API</h3> The Stream API may be used. However, because an instance is generated for each intermediate operation in the Stream API, performance may be worse than when using an enhanced for</code> loop. When implementing performance-critical processing, it is recommended to measure the performance of each approach before deciding which implementation method to use. var</code> (Local-Variable Type Inference)</h3> As a general rule, do not use var</code>. As can be seen from the widespread adoption of TypeScript and similar technologies, ensuring type safety</code> is strongly emphasized in modern team development. Robustness of the code should be prioritized over the reduced effort provided by type inference. However, its use is permitted in exceptional cases where not using var</code> would have a significantly greater disadvantage due to factors such as scope. Enable Console Login on a KVM Guest 2026-09-22T00:00:00+00:00 KVM provides a feature to log in to a guest via the console. However, if the guest itself is not configured to allow console login, you will not be able to perform any operations even after connecting. In particular, when the guest OS network settings are not yet configured, having console login available is very helpful (since you cannot connect via SSH to configure it). Below are the steps to configure a KVM guest. Environment</h2> KVM host OS : Rocky Linux 9 (upgraded from CentOS 8)</li> Bootloader : grub2</li> </ul> The KVM environment in use is built on RHEL clone (the KVM server runs on Rocky 9 : upgraded from CentOS), and the guests also use RHEL clone. Instead of installing OS from scratch every time, a base image is created in advance. When creating a new KVM guest, this base image is cloned. By enabling console login in the base image, all cloned guests will also support console login. Note: This procedure works with RHEL 7 and later. Earlier versions use grub</code> instead of grub2</code>, so the steps are different. Note: This article is based on content written and verified during the CentOS 8 era. Consequently, the output logs and version numbers (such as for the kernel and glibc) reflect that period; however, the same configuration procedures apply to RHEL 8/9 and Rocky Linux 9. Configuration</h2> Edit /etc/default/grub</code></h3> Modify the GRUB configuration. vi /etc/default/grub </code></pre> Change the following line: GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap"; </code></pre> to the following (add console=tty0 console=ttyS0,115200n8r</code> to the existing settings): 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> After editing, regenerate the configuration: grub2-mkconfig -o /boot/grub2/grub.cfg </code></pre> Reboot</h3> Reboot after changing the GRUB settings. reboot </code></pre> Verification</h2> After rebooting, verify that you can connect from the KVM host. Check the running guests: virsh list --all Id Name State ---------------------------------------------------- 1 mosaos-centos8 running 5 centos8-base running </code></pre> Log in via the console: virsh console centos8-base Connected to domain centos8-base Escape character is ^] 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> From here, you can proceed just as you would with a local login. If the login prompt does not appear, press the Enter key once. To exit, use ^]</code> (Ctrl</code> + ]</code>) as shown at the beginning. Note: Cockpit is also installed, and console login is available from Cockpit as well. It may feel similar to logging in from the AWS console. Changing the Disk Size of a KVM Guest 2026-09-22T00:00:00+00:00 Depending on the purpose of a KVM guest, the disk created initially may sometimes become insufficient in size. CPU and memory resources require a reboot, but can be changed relatively easily (subject to the resources available on the KVM host). Disk settings can also be changed flexibly when external disks are mounted using NFS or similar methods. However, changing the disk capacity of the image itself requires some work. Since this is the kind of procedure that is easy to forget if you do not write it down somewhere, I am documenting the steps here. Environment</h2> The environment is as follows. KVM host OS: Rocky 9</li> KVM guest OS: Linux-based (using LVM)</li> </ul> The image file format I use is qcow2, so the following procedure is for qcow2. Procedure</h2> * Before starting, shut down the KVM guest whose disk capacity you want to change, and back up the image if necessary. * Since a mistake when operating the commands could, in the worst case, make the system unable to boot, I recommend making a backup. First, perform the following operations on the KVM host. Check the KVM image</h3> Check the format and size of the KVM image. qemu-img info /var/lib/libvirt/images/<image-file-name> </code></pre> Expand the file size</h3> qemu-img resize -f qcow2 <image-file-name> +10G </code></pre> * Change the +10G</code> part as appropriate for the amount by which you want to resize the disk. After running the command, run qemu-img info</code> again and make sure that the size has been changed correctly. From this point onward, the operations are performed on the KVM guest. Using fdisk</h3> Start the KVM guest with the image whose capacity has been increased. Run fdisk and recreate the partition. * Change the device name as appropriate for your environment. * Although there are explanations in the middle, everything up to entering q</code> is an operation performed with the fdisk command. fdisk /dev/vda </code></pre> Check the current state. Command (m for help): p (omitted) Device Boot Start End Sectors Size Id Type /dev/vda1 * 2048 2099199 2097152 1G 83 Linux /dev/vda2 2099200 41943039 39843840 19G 8e Linux LVM </code></pre> Resize the LVM on /dev/vda2</code>. First, delete it: Command (m for help): d Partition number (1,2, default 2): 2 </code></pre> Then create it again. Since the basic partition 2 was deleted, recreate basic partition 2. When entering the number of sectors, the default value (just press Enter) is fine. (It will be created using all available free space.) Command (m for help): n Partition type p primary (1-4) e extended Select (default p): p Partition number (2-4, default 2): 2 First sector (2099200-41943039, default 2099200): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2099200-41943039, default 41943039): Created a new partition 2 of type 'Linux' and of size 19 GiB. Partition #2 contains a LVM2_member signature. Do you want to remove the signature? [Y]es/[N]o: N </code></pre> Change the partition type to Linux LVM</h3> The recreated partition type is Linux</code>, so change it to Linux LVM</code>. Command (m for help): t Partition number (1,2, default 2): 2 Hex code or alias (type L to list all): 8e Change type of partition 'Linux' to 'Linux LVM'. </code></pre> Check the state after the change: Command (m for help): p (omitted) Device Boot Start End Sectors Size Id Type /dev/vda1 * 2048 2099199 2097152 1G 83 Linux /dev/vda2 2099200 41943039 39843840 19G 8e Linux LVM </code></pre> If it has been changed to the expected state (size and partition type), write the changes and exit fdisk. Command (m for help): w Command (m for help): q </code></pre> On current operating systems (Red Hat 7 and later), partprobe</code> should allow the changes to take effect without rebooting. * A reboot may be required depending on the OS. * partprobe</code> itself may not even be necessary. partprobe </code></pre> Resize the physical volume</h3> When using LVM, you need to resize the PV (physical volume) and LV (logical volume). First, resize the PV (Physical Volume). Check the current state: pvdisplay </code></pre> Then resize it. This changes it so that all of the space corresponding to the size changed with fdisk is used. pvresize /dev/vda2 </code></pre> After resizing, run pvdisplay</code> again to confirm the change. Resize the logical volume</h3> Resize the logical volume. Check the current state: lvs lvdisplay </code></pre> Then resize it. lvextend -l +100%FREE /dev/cl/root </code></pre> Finally, expand the file system. xfs_growfs /dev/cl/root </code></pre> ※ On Ubuntu, you may need to use something like resize2fs /dev/ubuntu-vg/ubuntu-lv</code> instead. Check the size. 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> If the capacity has been expanded, the operation was successful. Building a Docker Repository with Nexus Repository Manager 2026-09-22T00:00:00+00:00 Introduction</h2> This article is a rewrite of an old article, so some information may be outdated. However, the NXRM built using this procedure is still running as of September 2026. </blockquote> It seems that the use of Docker has been increasing, but Docker images were not shared between developers. When using Docker, each developer had to build the images from Dockerfiles individually, which was inconvenient. To solve this problem, I built a Docker repository. The procedure for building and using it is described below. I used Nexus Repository OSS</a> (NXRM</code>) to build the repository. NXRM is an OSS repository manager that can be used not only for Docker repositories, but also for various libraries and images such as Maven. It can also work as a proxy for Docker Hub. In addition, by merging a private (hosted) repository with an external (cached) repository using the group repository feature, internal and external repositories can be handled transparently. ECR (Elastic Container Registry), etc. can also be used, but NXRM may be easier to adopt for teams where it is difficult to use such services because of cost. In an internal LAN, it is also possible to cache Docker images and various libraries to reduce traffic.</li> It is also possible to build an image with GitLab CI, and then register (push) the image to NXRM. GitLab can also be self-hosted.</li> </ul> </blockquote> Using NXRM may solve repository-related problems. If you have problems like those described above, it may be worth trying. Environment</h2> OS: CentOS 8</code> (built as a KVM guest) Currently upgraded to Rocky 9</code></li> The repository directory is mounted from a directory on the host. Since the cache repository tends to become large, I thought mounting a directory from the host would be easier to manage than managing it inside the KVM guest.</li> I initially tried to use 9p_virtio, but it did not work well, so I use NFS.</li> Configuring Blob Stores</a> says to use NFS v4, so I use NFSv4.</li> Configure the NFS server on the KVM host in advance.</li> The directory on the host is /var/opt/nexus</code>.</li> </ul> Prerequisites</h2> TLS (HTTPS) is not enabled because this is operated in a closed environment with internal access only. There are several ways to enable TLS for NXRM. Please refer to the official documentation, etc.</li> nexus_hostname</code> is the hostname of the host where Nexus Repository Manager is installed. If the host cannot be accessed by hostname, an IP address can also be used.</li> </ul> Installation Procedure (Server)</h2> dnf update</h3> dnf update </code></pre> NFS Client Configuration</h3> Mount the directory on the KVM host using NFS. Install the package</h4> dnf -y install nfs-utils </code></pre> Edit the configuration file</h4> vi /etc/idmapd.conf </code></pre> Edit the following part: Domain = mosaos.local </code></pre> Mount</h4> First, check whether it can be mounted. mount -t nfs kvmhost:/var/opt/nexus /mnt </code></pre> If it works, unmount it. umount /mnt </code></pre> Add the configuration to /etc/fstab</code> so that it is automatically mounted. vi /etc/fstab </code></pre> Add the following: kvmhost:/var/opt/nexus /opt/sonatype-work nfs4 rw,sync,tcp,hard,intr,rsize=32768,wsize=32768 0 0 </code></pre> Mount it. mount -a </code></pre> Install NXRM</h3> Install it using ansible-playbook</code>. mosaos/sonatype-nexus3-ansible</a> Clone the project: git clone https://github.com/mosaos/sonatype-nexus3-ansible </code></pre> Run ansible-playbook: cd sonatype_nexus3_ansible ansible-playbook -i hosts site.yml </code></pre> NXRM Configuration</h3> The configuration is mostly based on the following article: Using Nexus 3 as Your Repository - Part 3: Docker Images</a> Create the following repositories: Name</th> Type</th> Port (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> The settings when creating each repository are as follows. docker-private</h4> Create it as docker (hosted)</code>.</li> Check HTTP and specify the port number (5001</code>).</li> Check Enable Docker V1 API:</code>.</li> </ul> docker-hub</h4> Create it as docker (proxy)</code>.</li> Specify https://registry-1.docker.io</code> for Remote storage:</code>.</li> Select User Docker Hub</code> for Docker Index:</code>.</li> Check Enable Docker V1 API:</code>.</li> </ul> docker-group</h4> Create it as docker (group)</code>.</li> Check HTTP and specify the port number (5000</code>).</li> Add the two repositories created above to Member repositories:</code>.</li> Check Enable Docker V1 API:</code>.</li> </ul> In my environment, I could not push unless Enable Docker V1 API:</code> was checked. </blockquote> Additional Firewall Configuration</h3> After creating the repositories, allow 5000/tcp</code> and 5001/tcp</code> on the host where NXRM is installed. firewall-cmd --add-port=5000/tcp --permanent --zone=public firewall-cmd --add-port=5001/tcp --permanent --zone=public firewall-cmd --reload </code></pre> Installation Procedure (Client)</h2> Set up the Docker environment. A configuration is required to connect to a repository that does not use TLS. Environment</h3> I confirmed this procedure with the following environment. OS: CentOS 8</li> Docker: 19.03.8</li> </ul> Connectivity Check</h3> When sending a request to NXRM with curl, if it returns a response saying that it is not a Docker request, it is 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> Configure daemon.json</h3> Create daemon.json</code> and configure Docker. vi /etc/docker/daemon.json </code></pre> When using a repository that does not use TLS, it must be specified in insecure-registries</code>. It is also possible to specify this every time on the command line, but it is troublesome, so I recommend configuring the Docker daemon. </blockquote> Add the registries created in NXRM to insecure-registries</code>. { "debug": true, "insecure-registries": ["nexus_hostname:5000", "nexus_hostname:5001"] } </code></pre> The configuration when also using the mirror setting is described below. </blockquote> After creating daemon.json</code>, restart the Docker daemon. systemctl restart docker </code></pre> Registering (Pushing) Docker Images</h2> Log in to NXRM</h3> Specify an NXRM user for the username and password. docker login nexus_hostname:5000 docker login nexus_hostname:5001 </code></pre> You will be asked to enter a username and password. Log in with your own account. A WARNING will be displayed when running the command, but if Login Succeeded</code> is displayed, the login was successful. The authentication information is recorded in ~/.docker/config.json</code> after running the command. </blockquote> Push</h3> Push the image to the hosted repository. docker tag image_name:version nexus_hostname:5001/image_name:version docker push nexus_hostname:5001/library/image_name:version </code></pre> For some reason, if I did not add library</code>, I got a 404 (NOT FOUND) when pulling. I think it may be necessary to use a tag such as accountname/imagename:version</code>, in the same way as Docker Hub. Official images do not have the account name part, but in this kind of tagging, they seem to be under library</code>. In fact, when I downloaded the official MariaDB image and checked it in the proxy repository, its name was library/mariadb</code>. </blockquote> Pull</h3> Check whether the pushed image can be retrieved. The destination is not the hosted repository that was registered above, but the group repository that combines the hosted and proxy repositories. docker pull nexus_hostname:5000/image_name:version </code></pre> Mirror Configuration</h2> With the configuration so far, it is possible to register (push) and retrieve (pull) Docker images that were created by ourselves from the repository server. However, with this configuration, our own images and external images (hosted on Docker Hub) cannot be handled transparently. Change the configuration so that they can be handled transparently. Specifically, even when retrieving an image hosted by ourselves, it should be possible to retrieve it without specifying repository-server:port</code>, as follows. When pushing, repository-server:port</code> must be specified. </blockquote> docker pull image_name:version </code></pre> Docker can be configured to use registry-mirrors</code> as a Docker Hub mirror, so it should be possible to solve this by configuring the group repository we created as the mirror. However, there is a problem where authentication information is not correctly passed to the mirror site, so some additional configuration is necessary. Reference: registry-mirrorsが機能しない</a> As a solution, I use the method described in Docker is not passing auth informations when pulling from a mirror registry #30880</a>, where the authentication information is overwritten on the Nginx (proxy) side and the request is sent to Nexus. Edit the nginx Configuration</h3> I finally used the following configuration. 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> When accessing a repository, the URL starts with /v1</code> or /v2</code>, so in this case the request is forwarded to the group repository. At this time, authentication information is set using proxy_set_header Authorization ...</code>. The Basic Authentication value to set in $authorization</code> can be generated as follows. echo -n 'username:password' | base64 </code></pre> The above configuration also outputs upstreamlog</code> so that the actual forwarding destination can be checked. I noticed the problem where pulling did not work unless I added library</code> when pushing by checking this log. If an image can be pushed but cannot be pulled and a 404 occurs, the URL that the Docker client uses to retrieve the manifests may be different from the location where the image was pushed. In this case, checking upstreamlog</code> may help solve the problem. Restart nginx</h3> Check that there are no problems with the configuration: nginx -t </code></pre> If there are no problems, restart it. systemctl restart nginx </code></pre> Client-side Configuration</h3> Change /etc/docker/daemon.json</code> as follows. Specify the Nexus host in registry-mirrors</code> and insecure-registries</code>. { "debug": true, "insecure-registries": [ "nexus_hostname", "nexus_hostname:5000", "nexus_hostname:5001" ], "registry-mirrors": [ "http://nexus_hostname" ] } </code></pre> Troubleshooting</h2> The mirror configuration was the most difficult part for me. When a problem occurs, I recommend checking the following. Docker (client-side) logs In my environment, they were output to syslog (/var/log/messages/</code>).</li> Nexus Repository Manager logs The output directory is /opt/sonatype-work/nexus3/log</code>.</li> nginx logs If you are using a proxy, also use the upstreamlog</code> described above.</li> </ul> Incorrect Request Destination</h3> When I pushed an image without adding library</code>, it was pushed to the hosted repository with the following structure: /v2 |- blobs | |- sha256:..... | |- sha256:..... | |- sha256:..... | |- sha256:..... |- image_name |- manifests | |- sha256:... |- tags |- latest </code></pre> After configuring the mirror, when I ran docker pull image_name</code>, the following error was output in the Docker log: 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> I found that it was accessing /v2/library/image_name/...</code>. (In fact, I noticed this from upstreamlog</code> before checking the Docker log.) After pushing the image again as follows, I confirmed that it could be pulled. docker push nexus_hostname:5001/library/image_name:latest </code></pre> docker pull image_name </code></pre> References</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> Wedding Dress 2026-09-22T00:00:00+00:00 Why did I make it?</h2> My late wife (a graduate of SVA in NYC who passed away young from lung adenocarcinoma) apparently wanted to wear a dress she had imagined for our wedding, so I made one that was as close to her vision as possible. :D Her image was that of a fairy. It was quite different from an ordinary wedding dress, with a single piece of fabric softly spreading out from the chest. In the front, the fabric curled inward just above the knees, while in the back, the drape flowed naturally like a conventional wedding dress. We looked at quite a few dresses while shopping for one, but there was nothing that matched her vision. So I decided to make one myself... Material Procurement</h2> I went looking for fabric in Nippori Textile Town and eventually found what I needed at Tomato, a fabric store there. The dress wouldn't have the right shape without a petticoat, so I made that too. (I remember the petticoat actually took longer to make.) Later, one of my wife's friends said, "I'd love to wear it!" and my wife generously gave the dress to her. Leather Body Bag 2026-09-21T00:00:00+00:00 I made this body bag after the body bag I received from my late wife became worn out. The main part of the original bag had become badly worn, but the belt was still in good condition, so I reused the belt. I happened to find some nice Japanese leather at Hands Shinjuku during a leather fair featuring leather from Japanese tanneries, so I used it for this bag. I used black leather for the bottom part, with a separate piece for the transition. The leather parts were hand-stitched. The inner bag was sewn with a sewing machine. Nudibranch Pottery 2026-09-20T00:00:00+00:00 Inspiration</h2> My late wife (a graduate of SVA in NYC, who passed away at a young age from lung adenocarcinoma) practiced pottery painting. I also once made several ceramic figures by shaping pottery clay. Nudibranchs. I made these around the time I came across a book of nudibranch photographs and was fascinated by their beauty. What Happened Afterwards</h2> They were displayed at my wife's pottery exhibitions and other shows, but before I knew it, they had all disappeared. Maybe they're still with the people who bought them.

mosaos

Modifying a Speaker Protection Board

Modification</h2> First, here is a photo of the board after applying the modifications described above.</p> At this point, there are three modification areas (Section 1 - Section 3).</p>

Zola daisyUI blog

Introduction</h2> I created a blog template using Zola + daisyUI, so I am writing this article as a reminder for myself as well.</p> This article describes why I created it, the setup procedure, and so on.</p>

Why did I create it?</h2> I had been thinking about sharing personal information through GitHub Pages for some time, but I finally got around to building the application.</p>

Features</h2> This is the template I created. See README.md</code> for details, but it has the following features. Most of these are essentially characteristics of Zola/daisyUI and so on.</em></p>

Development Environment</h2> I have tested it with the following environment.</p>

Setup</h2> The application part is registered on GitHub as a template project. The recommended procedure is as follows.</p> Since symbolic links are used to check the site locally, WSL2 is recommended (when using Windows). I don't know about Mac.</em></p>

Keeping Up with Updates to zola-daisyui-blog</h2>

About Me

Main Career</h2> Current</strong>: Working at a company in Tokyo, engaged in application development and management of an engineering group, as well as promoting and leading internal study sessions and virtualization</li> </ul>

Best Practices for cron

Development</h2> First, some practices from the development side (cron implementers/configurators).</p>

Use /etc/cron.d</h3> Assuming that it is supported by the environment you are using, use /etc/cron.d/</code> if possible. * Do not edit crontab directly with crontab -e</code>.</p> Specifically, place multiple crontab configuration files under /etc/cron.d/</code>.</p>

Prevent multiple executions</h3> When implementing an application, it is possible to use mechanisms provided by the processing language (such as Java) to prevent multiple executions. However, multiple executions can also be prevented by using flock</code>, a standard Linux tool.</p>

Script</h4> Create a script containing the processing.</p> Create /root/scripts/sleep.sh</code> as follows.</p>

Operations</h2> Operational practices.</p>

Best Practices for GitLab

Introduction</h2> I have had both things that worked well and things that did not work well while using GitHub personally and GitLab for work.</p> Based on these experiences, I will summarize some Tips such as:</p>

Creating Branches</h2> When adding a new feature or fixing a bug, create a branch according to the branch strategy</code> defined/adopted by the project.</p> Branches can also be created on GitLab, but this has the following side effects.</p>

For Kanban</h3> Doing</code> In progress. Color: #5CB85C</li>

Close-related</h3> Used to classify Closed issues. Color: #808080</p>

Reference</h3> Milestones</a></li> </ul> Kanban</h2> It can be used from Issues</code> > Boards</code>.</p> GitLab calls this "Boards", but I think many people are more familiar with the term Kanban.</p> By default, GitLab provides the following states:</p>

Kanban</h2> It can be used from Issues</code> > Boards</code>.</p> GitLab calls this "Boards", but I think many people are more familiar with the term Kanban.</p> By default, GitLab provides the following states:</p>

Estimate</h3> You can enter an estimated effort by entering something like /estimate 1w 2d 5h</code> in an issue comment.</p>

Problems That Still Occurred</h2> Even if you establish rules such as the above, problems can still occur.</p> Here are some specific examples.</p>

What Is This Issue Supposed to Do?</h3> An issue was created with only a title, or with an insufficient overview, and it ended up in a "What is this supposed to do?" state.</p> The flow was something like this:</p>

Summary</h2> I really think you should stop using overly lax permission settings.</p>

Oracle User Management Best Practices

Terminology</h2> Let me define a few terms first.</p>

Best Practices</h2>

Grant privileges to roles, not users</h3> Oracle provides a mechanism for handling roles (ROLE), so instead of granting privileges to individual users, assign privileges to roles and configure individual users to belong to those roles.</p>

Perform auditing</h3> Oracle provides mechanisms for auditing login attempts and operations. If auditing is disabled, enable it so that sufficient auditing can be performed.</p>

Lock default users whenever possible.</h3> [第21回] Users created by default from the beginning</a> are among the easiest accounts for attackers to target, so it is preferable to lock them whenever possible. For accounts that cannot be locked, set sufficiently strong passwords.</p>

Nest roles</h3> Oracle roles can be nested. I have never configured this personally, but I have seen setups such as the following:</p>

Be careful with PUBLIC</h3> When privileges are granted to PUBLIC, anyone can use those privileges.</p> [第22回] Be careful with PUBLIC</a></p>

Determine roles based on use cases</h3> Consider the following based on actual operations. As much as possible, create and visualize an access matrix or something similar to organize the privileges.</p> Users Who are the users that access the database? What types of users are there?</li>

Redmine Best Practices

Adding too many members</h3> Was it too much trouble to think about? There are way too many members, aren't there?</p> Basically, only add people who are actually involved in the project as members.</p> Want to let someone view it only? → If a public project is sufficient, that is enough.</p>

Coding Rules (Java)

Files</h2> Each public class should be placed in a file named after that class.</p> Do not write multiple public classes in a single file.</li>

File Hierarchy</h2> Follow Maven's standard directory layout.</p> Maven has been used as a de facto standard build tool for Java for a long time, and using Maven's standard directory layout makes the project structure easy for many Java developers to understand.</p>

Naming Conventions</h2>

Uppercase and Lowercase</h3> Java is case-sensitive, but do not write code that distinguishes identifiers solely by differences in uppercase and lowercase letters.</p> Bad example)</p>

Implementation Class Names</h3> If it is necessary to distinguish an implementation class from its interface, append Impl</code> to the end.</p>

Loop Counters</h3> Use i</code>, j</code>, and k</code> for loop counters with a narrow scope.</p>

Instance Variables</h3> As a general rule, use private scope and write setters/getters as necessary. For simple setters/getters that only set or retrieve values, use Lombok</a> as appropriate to improve code readability and development efficiency.</p>

Modification</h2>
First, here is a photo of the board after applying the modifications described above.</p>
At this point, there are three modification areas (Section 1 - Section 3).</p>

Introduction</h2>
I created a blog template using Zola + daisyUI, so I am writing this article as a reminder for myself as well.</p>
This article describes why I created it, the setup procedure, and so on.</p>

Setup</h2>
The application part is registered on GitHub as a template project. The recommended procedure is as follows.</p>
Since symbolic links are used to check the site locally, WSL2 is recommended (when using Windows).
I don't know about Mac.</em></p>

Main Career</h2>

Current</strong>: Working at a company in Tokyo, engaged in application development and management of an engineering group, as well as promoting and leading internal study sessions and virtualization</li> </ul>

Development</h2>
First, some practices from the development side (cron implementers/configurators).</p>

Operations</h2>
Operational practices.</p>

Problems That Still Occurred</h2>
Even if you establish rules such as the above, problems can still occur.</p>
Here are some specific examples.</p>

Summary</h2>
I really think you should stop using overly lax permission settings.</p>

Perform auditing</h3>
Oracle provides mechanisms for auditing login attempts and operations.
If auditing is disabled, enable it so that sufficient auditing can be performed.</p>

Lock default users whenever possible.</h3>
[第21回] Users created by default from the beginning</a> are among the easiest accounts for attackers to target, so it is preferable to lock them whenever possible.
For accounts that cannot be locked, set sufficiently strong passwords.</p>

Be careful with PUBLIC</h3>
When privileges are granted to PUBLIC, anyone can use those privileges.</p>
[第22回] Be careful with PUBLIC</a></p>

Adding too many members</h3>
Was it too much trouble to think about? There are way too many members, aren't there?</p>
Basically, only add people who are actually involved in the project as members.</p>
Want to let someone view it only?
→ If a public project is sufficient, that is enough.</p>

File Hierarchy</h2>
Follow Maven's standard directory layout.</p>
Maven has been used as a de facto standard build tool for Java for a long time, and using Maven's standard directory layout makes the project structure easy for many Java developers to understand.</p>

Implementation Class Names</h3>
If it is necessary to distinguish an implementation class from its interface, append `Impl</code> to the end.</p>`

Loop Counters</h3>
Use `i</code>, j</code>, and k</code> for loop counters with a narrow scope.</p>`

Instance Variables</h3>
As a general rule, use private scope and write setters/getters as necessary.
For simple setters/getters that only set or retrieve values, use Lombok</a> as appropriate to improve code readability and development efficiency.</p>