I love software2!

スタティックメソッドはどうですか

ちょっと、仕事プログラムで1つのファイルが肥大化傾向があって、「Java クラス分割」というキーワードでググってみた。
そもそもJavaってのはクラスを分割して書けないという融通の利かない言語で、割と常識的なこととか初心者向けのことを書いてるページが並ぶ。

『何をクラス分割の指針とすべきか』（https://iwamototakashi.hatenadiary.jp/entry/20090530/p1）に書いてあるLCOM (Lack of Cohesion in Methods) ってのが面白い。
元ネタはITmedia。

で、常々失敗したOOPプログラムに接していると、いかに変数を減らすか、いかにインスタンスを減らすかばかり考えているわけですよ、最近は。
で、先程のページの

『ちなみにインスタンス変数のないクラスは、ほぼ不要であると個人的には思っています。そのようなクラスは、
スタティックメソッドの集まりになるのでしょうが：

Static methods are procedural! In OO language stick to OO. And as far as Math.abs(-5) goes, I think Java got it wrong.
I really want to write -5.abs(). Ruby got that one right. Static Methods are Death to Testability

という Miško Hevery 氏の意見(http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/)に私は賛成です。』

なんてことを読んじゃうと、喧嘩売ってんのかと思う。いやまぁ、勝手に読んでるのは私ですが。10年も前の記事なんで、今でも同じ考えとは限らないなと思う。

例に上がってるMath.abs(-5)の書き方は重要ですよ。これ、どっからでも呼べますから。
色々考えて最近はDBのテーブルアクセスは全部スタティックメソッドにしてる。SampleTbl.Record rec = SampleTbl.getById(String id)って感じ。
OOP的な意味では全てファクトリですよ。ファクトリしかないのだから全部スタティックメソッド。
レコードは普通にクラスなんで好きにすればいいけど、本質的にはget/setしかない。
で、SampleTbl.getByIdはコード上どこからでも好きに呼べるのが重要。誰がDBアクセスインスタンスを持ってるかとか気にしない。
そういうのは基本戦略としてメソッド内に封じ込める。

まぁ、スタティックメソッドの集まりに価値のある応用もあるってこと。

あと、Math.abs(-5)を先に作って、-5.abs()は最終的にMath.abs(-5)を呼ぶというような実装もよくやる。逆ではない。

私も関数型言語に触れるまではスタティックメソッドを活用しようとはあまり思わなかった。この10年でだいぶコードの書き方が変わった。

モンティ・ホール問題

三つの選択肢のどれかが当り。出題者はどれが当りか知っている。
回答者が選択した一つ以外の残り二つから出題者がはずれを選んで開ける。
さて、回答者は選択を維持するか変えるかどっちが有利か。これがモンティ・ホール問題。

モンティ・ホール問題が納得いかなくて、なるべく愚直にプログラムを書いてみようかと思い、
具体的にどう書こうかと考えてる間に納得してしまった。でもPythonで一応愚直に書いてみた。
「モンティ・ホール問題プログラム」でググると似たような愚直なプログラムを書いた人は結構いるので掲載はしない。

Ubuntu 18.04のカスタマイズ

最近Ubuntuを使いにくいなぁと思っていた。問題はGUIで上にバッテリーステータスや日付表示されるパネルのフォントサイズを変更できなかったからだ。
UbuntuがUnityをやめてGNOME 3に移行したことで、どうやって設定変更したら良いのかわからなくなったのだ。VAIO Pro 11は割と画面解像度が高いので、
そのままでは非常に小さい文字しか表示されない。FirefoxやTerminalは個別にフォントサイズを大きくできるのでいいのだが、パネルに表示される日付やらバッテリー残量やらアプリのメニューやらは小さいまま。Unityの頃はディスプレイ画面のdpiを指定することで全体の文字サイズを調整できたのだがそういった機能はなくなったようだ。Kotlinのお試しのためVAIOを活用しようかなと思い、ちょっとググる。

GNOME 3のExtensionでUser Themesを有効にする。~/.themesに独自テーマのディレクトリを用意し、~/.themes/<テーマ名>/gnome-shell/gnome-shell.cssを作る。

# gnome-shell.css
stage {
    font-size: 18pt;
}

Tweaksの[外観 – テーマ – GNOME Shell]で上記<テーマ名>を選ぶ。
これでようやくGNOME 3のパネルの文字が読めるようになる。ともかく老眼には厳しい話だ。

GNOME 3のウィンドウマネージャはMutterというそうだ。dconf-editorでorg.gnome.mutterに幾つか設定がある。
edge-tilingをオフにすると、Ubuntu 18.04でかなりイライラさせられる「ウィンドウを移動させたいだけなのに、
上に持っていくと最大サイズにされてしまう」という問題が解消する。あぁ、嬉しい。

Ubuntuを起動したまま放置すると例えば30分でブランクスクリーンになるように設定している。
マウスを動かしたりするとブランクスクリーンを解除するのだが、Unityの頃にはなかった変な画面になっている。
真ん中にドカンと時計が表示されるロック画面とは違う謎画面。この画面の解除にはキーボード入力を要求する。いや、正確ではないな。
マウスで解除する方法はあるにはあるが、タッチスクリーンにおけるスワイプアップ相当の動きをマウスで行う必要がある。
これ決めた人は明らかに変。どう考えてもおかしい。キーボードくらい押せばいいとか思うでしょ。マシンを落とす（パワーオフにする）にはメニューから電源オフをするのが正しい手順で、
キーボードがなくてもちゃんと行える。逆に、キーボードに電源ボタンがない限り、キーボードだけでマシンを落とす方法はUIには用意されていない。
ノートパソコンはキーボードの近くに電源ボタンがあるからマシだが、デスクトップ機の電源を落とすのに電源ボタンを押すなんてことは普通しない。
という状況にも拘わらずキーボードを要求する、GNOMEは。とにかくストレス。

GNOME Shell Extensionsに「Disable Screen Shield」というツールがあると知る。
その邪魔な画面はScreen Shieldというらしい。これを無効にしてくれる。あぁ、嬉しい。そもそもScreen Shield自体がオプトインにすべき機能だろうに、
更にはオプトアウトすら用意していない。「GNOME Screen Shield」でググると世界中で迷惑がられてます。