ログ日記

作業ログと日記とメモ

技術駆動パッケージングとstrict layered

一般的な用語かどうか分からないけど、DDDなどの構造に関する方式メモ。


「技術駆動パッケージング」
DDDをいざやろうとして、実際にファイルをどこに置くの?どういうカテゴリーでディレクトリにまとめるの?という疑問への回答。
これはアンチパターン派が多そう。

ただ、この図を見ると、コントローラーも同じディレクトリにまとめてしまった方が分かりやすくない?と思うのだけれど。
コントローラーやDBアクセス(リポジトリの実装クラス)ごと一つの機能の構成単位としてディレクトリにまとめてしまっても良いような。設計が綺麗じゃない感じがするけど、フレームワークもDBも変更しない前提なら特にデメリットは無いような気がする。



「strict layered と relaxed layered」
レイヤーを飛び越えてアクセスしても良いかどうか。
これはそれぞれ自分で選んでねということらしい。

qiita.com

詰め替えのコードが少ない手間で書けるのなら全部詰め替えた方が良いんだろうけど、増えてくると結構な手間がかかりそう。言語による?

ThinkPadに入れたDebianホスト VMware Windowsゲストでスマートカードリーダーを使う

ThinkPad の P17 のオプションでスマートカードリーダー付きにしたので使ってみる。
カーネル
Lenovo ThinkPad P17 に Debianをインストールする - ログ日記
ここで5.8 に更新済み。

まずはLinuxにカードリーダーを認識させる。

# uname -r
5.8.0-0.bpo.2-amd64

# lsusb |grep AU9540
Bus 001 Device 005: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader

apt install pcscd pcsc-tools

pcsc_scan を実行して、ICカードを挿して反応を見る。

# pcsc_scan
Using reader plug'n play mechanism
Scanning present readers...
0: Alcor Micro AU9560 00 00
 
Sat Feb 27 15:30:14 2021
 Reader 0: Alcor Micro AU9560 00 00
  Event number: 0
  Card state: Card removed, 

VMwareWindowsを立ち上げて、カードリーダーのドライバーをインストールする。
再起動して、メニューから Removable Devices => Shared Alcor Micro AU9560 00 00 => Connect をクリックしてWindowsに接続する。

バイスマネージャーに「スマートカード読み取り装置」が生えてきたらOK。


ちなみにUSB接続のACR39-NTTComは

UdevQt: unhandled device action "bind"

というメッセージが出るけど、認識に問題はないようだ。

 Reader 0: ACS ACR39U ICC Reader 00 00
  Event number: 4
  Card state: Card removed, 

同様にVMwareでconnectすればWindowsでも使える。

MacBook Proを修理に出した

バッテリーが膨張したので修理に出した。

結構前からこうなっていて、でも仕事用PCがこれしかなかったので修理に出せなかった。

MacBook Pro 2017 15inch の Touch Bar が壊れた - ログ日記
更に前からTouch Barは壊れていたんだけど、さすがにバッテリーがもし完全に壊れたらちょっと大変っぽいしね…。

ひとまず近所の代理店に予約を入れて話を聞くと、バッテリーの修理2万円またはTouch Barなどの修理で8万円になるとのことだった。
Touch Barがバッテリーが原因による故障でバッテリー修理のカテゴリーで直してもらって2万円で収まるのか、別要因で追加で費用がかかるのか、Appleに送ってみないと分からないということらしい。


その場ではひとまず持ち帰って、少し考えてちょっと遠いApple Storeまで行ってきた。
でも結局同じような回答だった。
代理店の手数料5000円分?だけ安いけど、これは配送修理と同じ値段なので交通費の分だけ若干損になったかもわからん。
いや、でも対面じゃない状態でチェックされて本体見ずに8万円って確定されたら困るし、しゃーない。配送修理ってどうやって見積もるんだろう。

Apple Storeの人は、とりあえず2万円で送っておきますね〜金額は変わるかも〜ということだった。
どうなることやら。
iPhoneはかなり長持ちしてるからMacBookも丈夫なんだと勝手に思ってたけど全然そんなことなかったようだ。

中のデータは、わざと消すようなことはないのでなるべく残すという方向になるようだ。


# 2/23 追記

2/20 に修理から返ってきた。
金額は2万円でいけたようだった。
Touch Barもバッテリー価格で直してもらって、ひとまず安心。ディスクも元のままだった。
修理の前にアップデートしたらKarabiner-Elementsが動かなくなってアップデートもエラーになったので新しいバージョンをDLして再インストールした。

Apple Storeで聞いた話だと、電源を繋ぎっぱなしで使っているとバッテリーが膨張しやすい模様。
電源を繋ぎっぱなしの方が良いという意見と繋ぎっぱなしはダメという意見が両方あってどちらが本当か分からないが、ひとまずApple Storeで聞いたことを信じて充電100%に近いときは電源を繋がないようにしてやってみる。


バッテリー膨張したMacBook Pro(2017, 15-inch)を修理に出したら無料&3日で帰ってきた - ほりべあぶろぐ
何かMacBook Pro 2017 15-inch 特有の問題があったのかな?
最初にちょっとおかしかった段階で修理に出していたら無料だったりしたのだろうか…。

MacBook Pro (15-inch, 2018) のバッテリーが膨張してトラックパッドが浮き上がってきたので修理に出してきた話 | Interest Speaker
2018の例。当たりハズレがあるのだろうか。

Debian 10 buster に swift をインストールして GTKとQt の GUIデモを動かした

https://swift.org/download/#releases
ここからUbuntu18用のファイルを持ってくる。20はglibcのバージョン違いで動かなかったので18で。


How to Install Swift on Debian 10 (Buster) – Step By Step: Linuxs
ここに書いているコマンドをそのまま実行。

apt install libncurses5 clang libcurl4 libpython2.7 libpython2.7-dev

mv swift-5.3.3-RELEASE-ubuntu18.04.tar.gz /opt/
cd /opt
tar xvzf swift-5.3.3-RELEASE-ubuntu18.04.tar.gz
ln -s swift-5.3.3-RELEASE-ubuntu18.04 swift

DLしたswiftのディレクトリを名前を変えて /opt に移動して /opt/swift/usr/bin のPATHを設定する。

swift --version
Swift version 5.3.3 (swift-5.3.3-RELEASE)
Target: x86_64-unknown-linux-gnu


LinuxでもSwiftを使ってGUI開発をしたい!【SwiftGtk】 - Qiita
ここを参考にしようと思ったけど、TomasLinhart/SwiftGtk のバージョンが古いようなので
GitHub - rhx/SwiftGtk: A Swift wrapper around gtk-3.x and gtk-4.x that is largely auto-generated from gobject-introspection
こっちを設定。何やら関連プロジェクトや依存パッケージが多くて複雑っぽい。


Hello Worldのビルドにかなり時間がかかるんだが、こんなもんなんだろうか。
.build/ ディレクトリが 1.4GBある。
.build/x86_64-unknown-linux-gnu/debug/ が984MB。

swift build -c release

でリリースビルドになるようなので、やってみるとこちらもかなり時間がかかる。
.build/x86_64-unknown-linux-gnu/release/ は317MB
.build/x86_64-unknown-linux-gnu/release/HelloGtk は57MBだった。Hello Worldで57MB…。


コンパイルするタイプの言語は -j オプションで分割コンパイルできるということを思い出して、-j 8 でやってみる。結構早くなったけどそれでも遅い。
使わない機能もとりあえず全部まとめてswift用に変換とコンパイルしているような動きだ。
そういえばghcjsでもgoでも同じような感じだった気がする…。とりあえず各種デモプログラムは動くことを確認した。毎回githubからDLするのもどうかと…まあこれは今風か。



GTKじゃなくてQtを試そうと
GitHub - therecipe/swift: Qt binding for Swift | Showcase example for https://github.com/therecipe/qt
こっちも入れてみたけど、イマイチどういう動きになっているのか分からず…。
また今度続きをやろう。


とりあえず何かの言語でGUIという場合はswiftより先にgoをやった方が良いかもわからんね。

Debian の VMwareが遅いのでtransparent_hugepageを無効化する

LinuxVMwareWindowsを動かしていて、大きなファイルを開いたりすると固まるときがある。
kcompactd0 が CPU 100% になっている。vmwareも600%になっていたりする。

メモリは十分あってLinuxWindowsもfreeが残っている。

www.linuxquestions.org

transparent_hugepage を never にしてオフにすれば良い?
少し改善した気がする。

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

defragだけneverにしてenabled にしてtransparent_hugepage/enabledは madvise にでも設定すれば良い?
まだあまり意味が分かってない。


説明だけ読むと、有効の方が良さそうな機能なんだけど。


Fixing khugepaged CPU usage VMware Workstation · GitHub
Solved: Client machines freeze momentarily but regularly -... - VMware Technology Network VMTN
Linux Host/Windows 10 Pro 64 Guest - Host Freezes ... - VMware Technology Network VMTN

VMwareを使うならオフにするのが良さそうだ。



Debian の rc.local は今はsystemd管理になっているっぽいので有効化する。
【2020年最新版】Debian 10 Busterに/etc/rc.localを導入する
起動が数秒遅くなった。

# 2/4 追記
/etc/rc.local の実行ファイルがある場合は自動でサービスが起動されるっぽい。
あと、rc.localが実行された場合はスピーカーがオンにならなかった。何かが干渉している?とりあえずオフに戻してブートパラメーターで設定した。


vi /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=never"
update-grub

2020年のやったことまとめと2021年のやること

2019年〜2020年の前半まではひたすらリニューアルのコードを書いていた。
最終的なサーバーの構成は、いつも通りさくらクラウドPHP、DB、Web Proxyの構成にした。

現状、DockerはCIで使うだけになっている。
重いので今はこれも別のものに変えたくなってきているところ。

systemd-nspawnはテストサーバーで使っている。
結構快適だけれど、コマンド一つでサーバーを増やしたり消したりして柔軟にクラスタを構成するレベルには至っていない。
結局サーバー管理からは逃れられていないのであった。
コンテナを使った場合のセキュリティ更新の仕組みがあまり分かっていない。結局OSのアップデートを毎日確認する昔ながらの運用になった。

サーバー監視もkibanaをやめてcactiに戻した。cactiというかrrdがディスクを食わなくて良いんだよね。



開発PCはMacからLinuxに戻した。
PhotoshopやOffice以外は快適になった。


PHPのプログラムは、テンプレートエンジンをやめたくなってDDDを一部導入したくなって、中途半端に手を付けた状態。
綺麗なコードにできるのはいつだろう。



なんか新しいことをやってみようとしつつ、結局今の規模感だと昔のやり方に戻した方がやりやすいということだった。
あと今まであまり細かく調べてこなかったSEOをやっている。
プログラムやサーバー云々よりも、結局は売上に直結するSEOが重要なので…。


会社の仕事以外には、これもいつも通りちょっとしたサーバー系の設定とかWordPressとかをやった。
ほとんど新しいことはやっていないね。



以前から度々GUIのプログラムを作りたくなったりするんだけれど、手を付けれていない。
今年の目標も…うーん。
なんか趣味のプログラムを書く時間というか気力が減ってきている気がする。
何年も前に作った自分用ツールのプログラムも綺麗にしたいし、手動でやっている定期的な作業も自動化したいし、スマホでメール送信して後でPCでチェックしている作業もアプリか何かでやりたいし、細かいことは色々ある。
今年はそのうちどれかをやろう。

PHPのベンチマークを検証しようとしたらfanが動いてなかった件

https://qiita.com/okdyy75/items/c6f1469ed6a74a075151
https://qiita.com/Maki-Daisuke/items/23c1285500208048de80
これを自分でも検証しようと実行してみた。
PHPがそんなに遅いわけないと思って。

% cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

% docker --version
Docker version 18.09.1, build 4c52b90

% grep 'model name' /proc/cpuinfo |head -n 1
model name      : Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz

% grep processor /proc/cpuinfo |wc -l
12

% free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi       5.5Gi        19Gi       532Mi       6.3Gi        24Gi
Swap:          31Gi          0B        31Gi

# nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     NY06N091510306P5E    SKHynix_HFS512GD9TNI-L2B0B               1         512.11  GB / 512.11  GB    512   B +  0 B   11710C10
/dev/nvme1n1     50TF30EWF6C1         KXG6AZNV256G TOSHIBA                     1         256.06  GB / 256.06  GB    512   B +  0 B   5107AGLA
git clone https://github.com/okdyy75/bench-docker.git
cd bench-docker/
docker-compose up -d


Go

docker-compose run --rm golang sh -c 'cd go; go build . && ./go'
 ・・(snip)・・
4.8882788 (0x0,0x0)
4.9010998 (0x0,0x0)
4.9262488 (0x0,0x0)
4.9179488 (0x0,0x0)
16.1521789 (0x0,0x0)
51.1434579 (0x0,0x0)
51.2540279 (0x0,0x0)
51.1595889 (0x0,0x0)
51.3981269 (0x0,0x0)
50.5078839 (0x0,0x0)
平均秒数:29.12488324 (0x0,0x0)

Python

docker-compose run --rm python sh -c 'cd python; pip install -r ./requirements.txt && python bench.py'
5.247909
5.105158
5.189029
5.159607
19.598987
44.922379
50.793592
50.576921
50.310744
50.391779
平均秒数:28.729611

PHP

5.5343110561371
4.8346080780029
4.8351881504059
4.7622499465942
4.7532980442047
37.027944087982
49.002175092697
48.619991064072
48.726005077362
48.607387065887
平均秒数:25.670315766335

なんか途中から速度がおかしいね。
Dockerがダメなのかと思ってローカルでそのまま実行したり、PostgreSQLで実行しても同じような傾向になる。
ハードのリソースを使いすぎるとノートパソコンが何らかの制御をしているのか?

2020-12-17 08:06:18.433000
2020-12-17 08:06:18.480800 import CSV start
2020-12-17 08:07:02.661400 import CSV end
2020-12-17 08:07:02.693900 export CSV start
2020-12-17 08:07:02.713000 export CSV end
2020-12-17 08:07:02.713000 compare CSV start
2020-12-17 08:07:02.855700 compare CSV end
2020-12-17 08:07:02.856700
44.423780202866

DBの1万件インサートが遅い。
prepareを一度だけ実行するようにすると少し早くなるけど、8〜9件目ぐらいから結局遅くなる。
ファンが動いてなかったりcpufreqが極端に低くなったりしたので、cpufrequtilsを入れたりthinkfan関連を入れたりした。
ファンは動くようになってcpuクロックも高めにしたけど、やっぱり途中から遅くなる。
少電力系か・・・?
CPUも温度もファンもあまり使ってない段階で遅くなるんだよな。
また今度調べよう。