2021-02-13

MacBook Proを修理に出した

Mac

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

結構前からこうなっていて、でも仕事用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の例。当たりハズレがあるのだろうか。

2021-01-30

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

Debian Swift

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をやった方が良いかもわからんね。

2021-01-28

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

Linux

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

メモリは十分あってLinuxもWindowsも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

2021-01-11

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でチェックしている作業もアプリか何かでやりたいし、細かいことは色々ある。
今年はそのうちどれかをやろう。

2020-12-17

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

Debian

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

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も温度もファンもあまり使ってない段階で遅くなるんだよな。
また今度調べよう。

2020-12-11

Debian の LibreOffice が重すぎる件

Debian

Debian 10 buster をインストールしてからLibreOfficeが重すぎる。
Calcの計算とかWriterの画像とかじゃなくて、空で立ち上げてメニューを表示するだけでも重い。
PCのスペックは圧倒的に上がったはずなのに、重い。
ちょっと動かすだけでCPUが100%になる。

askubuntu.com
GTK関係？スケーリング解像度の影響だろうか。
Eclipseも動作が不安定だったし。

仕方がないのでDebianのLibreOfficeパッケージはapt remove --purge libreoffice* で全て削除して apt autoremove --purge してから
www.libreoffice.org
本家のdebパッケージでバージョン7をインストールした。
めっちゃ軽くなった。

2020-12-05

PHPの静的解析 Phan/Psalm/PHPStan の違い

PHP

エラーチェックのためにPHPで静的解析ツールをする場合、Phan, Psalm, PHPStan を使えば良いということは検索ですぐ出てくるのだが、どれを使えばいいのか。
それぞれのツールで検知できるものが微妙に異なっているので、全部使うのが安全ではある。

それでも動作の違いや思想の違いを知っておきたいので調べる。

github.com
github.com
github.com

自分がエラーを検知してほしいまたは正しく型チェックしてほしいと思うコードを用意してそれぞれチェックしてみるのが手っ取り早い。
思いつくコードを調べてみた。
設定は基本的に初期のまま。PhanはREADMEにある設定、Psalmはレベル1、PHPStanはレベル8にした。（PsalmとPHPStanで検知レベルの向きが逆である）

<?php
/**
 * @param array<int,string> $arr
 */
function test1(array $arr, ?int $index): ?string
{
    $ret = null;
    if (isset($arr[$index]))
        $ret = $arr[$index];
    return $ret;
}

Phan	Psalm	PHPStan
PhanTypeMismatchDimFetchNullable	エラーなし	エラーなし

Phan は配列のインデックスに nullable な値を指定するとエラーになる。

<?php
/**
 * @param array<int,string> $arr
 */
function test1(array $arr): ?string
{
    if (isset($arr[null]))
        return $arr[null];
    return null;
}

Phan	Psalm	PHPStan
PhanTypeMismatchDimFetchNullable	NullArrayOffset	エラーなし

こちらはPsalmでもエラー。
PHPの文法的にはOKだが、null は自動的に空文字 '' に変換されるので、PHPStanも正しくはない。

<?php
/** @return mixed */
function test2()
{
    $a = $_GET['a'];
    return $a;
}

Phan	Psalm	PHPStan
エラーなし	MixedAssignment	エラーなし

Psalm は mixed の扱いに厳しい。

<?php
function test3(): int
{
    throw new Exception('err');
    return 0;
}

Phan	Psalm	PHPStan
PhanPluginUnreachableCode	エラーなし	Unreachable statement

Psalm は未到達コードをチェックしないようである。
https://github.com/vimeo/psalm/issues/403#issuecomment-354441656
オプションを付ければチェックされるようだが、デフォルトではreturnやexitの後のコードはチェックされないようだ。

<?php
/**
 * @template T of DateTimeInterface
 * @param T $d
 * @return T
 */
function test4($d)
{
    $d->format('d');
    return $d;
}

Phan	Psalm	PHPStan
PhanUndeclaredClassMethod	エラーなし	エラーなし

Phanはジェネリクスに of が使えないようだ。

<?php
function test4(): void
{
    var_dump(1);
}

Phan	Psalm	PHPStan
エラーなし	ForbiddenCode	エラーなし

Psalm は var_dump がエラーする。
エラーを見る限り、危険な関数の使用自体がチェックされるようである。

<?php
/**
 * @template T of DateTime
 * @template U of DateTime
 * @param iterable<T,iterable<string,U>> $dss
 * @param callable(string):int $f
 * @return ?int
 */
function test5($dss, $f)
{
    foreach ($dss as $k => $ds){
        foreach ($ds as $s => $d){
            $diff = $k->diff($d);
            if ($diff->format('%d') == 10)
                return $f($s);
        }
    }
    return null;
}

Phan	Psalm	PHPStan
PhanUndeclaredClassMethod	エラーなし	エラーなし

Phan は of が使えないのでエラー。PsalmもPHPStan も入れ子のジェネリクスとコールバック関数の型を理解できる。試しに戻り値の型を ?string にするとエラーになる。

<?php
function test6($a)
{
    echo 'a';
}

Phan	Psalm	PHPStan
エラーなし	MissingParamType, MissingReturnType	parameter $a with no typehint specified, no return typehint specified

PHPStanの方がエラーが詳しいような書き方になってしまったがそうではなく、Psalm のようなエラーの型がないだけである。Psalmも詳しいメッセージは出力されている。
Psalm と PHPStan は型が必須のようだ。

<?php
/**
 * @template T
 * @param class-string<T> $c
 * @return T
 */
function test7($c)
{
    return new $c;
}

Phan	Psalm	PHPStan
エラーなし	MixedMethodCall	エラーなし

Psalm は mixed に厳しい。コンストラクタの引数が分からないのでnew できるかは不明というのは正しい。

<?php
interface Foo {
    public function bar(string $bar, int $baz): int;
}
class FooImpl implements Foo {
    public function bar(string $_, int $i): int
    {
        return $i++;
    }
}

Phan	Psalm	PHPStan
PhanParamNameIndicatingUnused	ParamNameMismatch	エラーなし

PhanとPsalmはパラメーター名が異なればエラー。
今までは単なるコード整形だったけれども、PHP8 で named parameters が来ると意味が変わってくる。

<?php
abstract class P
{
    abstract protected function a(DateTimeImmutable $d): DateTimeInterface;
}
class C extends P
{
    protected function a(DateTimeInterface $d): DateTimeImmutable
    {
        return new DateTimeImmutable($d->format('y-m-d'));
    }
}

Phan	Psalm	PHPStan
PhanParamSignatureRealMismatchParamType, PhanParamSignatureRealMismatchReturnType	MethodSignatureMismatch	エラーなし

PHPStanだけPHPの文法に合うようになっている。 (※コメントも参照)
PhanとPsalmはわざとエラーにしている？でもエラーメッセージを見ると共変性と反変性をあえて禁止にしているようには見えない。

<?php
function test8(int $i): bool
{
    switch(true){
    case $i <= 10:
        return true;
        break;
    case $i > 10 && $i <= 20:
        return false;
        break;
    default:
        return true;
        break;
    }
    return true;
}

Phan	Psalm	PHPStan
PhanPluginUnreachableCode	エラーなし	Unreachable statement, Comparison operation ">" between int<11, max> and 10 is always true.

Psalm はデッドコードをチェックしない。
PHPStanは、条件10がかぶっていることを見つけてエラーにする。

<?php
function test9(string $s): string
{
    return sprintf('foo%s, %s', $s);
}

Phan	Psalm	PHPStan
PhanPluginPrintfNonexistentArgument	エラーなし	Call to sprintf contains 2 placeholders, 1 value given.

PhanとPHPStan はsprintfのフォーマットをチェックする。

<?php
function test9(string $s): string
{
    return sprintf('foo%s, %s', $s, 1);
}

Phan	Psalm	PHPStan
PhanPluginPrintfIncompatibleArgumentType	エラーなし	エラーなし

Phanは更に型までチェックする。
PHPStan も実は型をチェックしていて、1をnew DateTimeに変えるとエラーになる。bool|float|int|string|null を受け付けるようだ。

さて、大まかな違いが見えてきた。
Phanは全体的にバランス良くチェックしようとしているが、ジェネリクスの機能が弱い。関数のシグネチャに型がなくてもスルーする。レガシーコードに利用するのに向いていそうだ。
Psalmはmixedに厳しく、全ての型を指定しろという強い意志を感じる。新規プロジェクトに向いている。
PHPStanはPHPが許す文法には寛容に見えるし、mixedをスルーして共変性と反変性を正しく実装しているのは元々のPHPの動作を尊重しているからかもしれない。

※ この記事はQiitaの PHP その2 Advent Calendar 2020 の5日目の記事、今空いてたから登録した。

※ 12/7 追記
コメントをもらったので再チェック。
psalm の使い方が分かってないのかも…。

% ./vendor/bin/psalm --clear-cache
Cache directory deleted
% ./vendor/bin/psalm --version
Psalm 4.2.1@ea9cb72143b77e7520c52fa37290bd8d8bc88fd9
%
% ./vendor/bin/psalm
Scanning files...
Analyzing files...

E

ERROR: MethodSignatureMismatch - src/functions.php:9:5 - Method C::a with return type 'DateTimeImmutable' is different to return type 'DateTimeInterface' of inherited method P::a (see https://psalm.dev/042)
    public function a(DateTimeInterface $d): DateTimeImmutable


ERROR: MethodSignatureMismatch - src/functions.php:9:41 - Argument 1 of C::a has wrong type 'DateTimeInterface', expecting 'DateTimeImmutable' as defined by P::a (see https://psalm.dev/042)
    public function a(DateTimeInterface $d): DateTimeImmutable


------------------------------
2 errors found
------------------------------

Checks took 0.44 seconds and used 57.117MB of memory
Psalm was able to infer types for 100% of the codebase
%
% cat src/functions.php
<?php

abstract class P
{
    abstract public function a(DateTimeImmutable $d): DateTimeInterface;
}
class C extends P
{
    public function a(DateTimeInterface $d): DateTimeImmutable
    {
        return new DateTimeImmutable($d->format('y-m-d'));
    }
}

https://psalm.dev/r/52f57aeabe と結果が異なる。