A5:SQL Mk-2

積年の澱（おり）のように凝り固まった偏見を変節して Mac mini を買ってしまいました。先に白状すると、Apple M1 のベンチマークを見てシングルスレッドのパフォーマンスにビビってしまったのです。

色々考えているところはあって、Mac向けの Sequel Pro (Sequel Ace)を評価してみたいとか、Wineとか使ってA5:SQL Mk-2の動作を確認したい（CrossOver for Macもあるし、そのうちWineもM1対応するよね？）とか、仮想環境なりBootcampみたいな仕組みが出てきてARM Windowsが動くようになるでしょ？（そのうちMicrosoftもARM Windowsのライセンス発売するでしょ？）とか、どうにも使えなかったら仮想通貨でも採掘させてみるか（やったことない）とか、若干楽観的な認識のもとMac miniを買ってしまいました。

ARM Windowsを評価するだけならARM Windowsマシンを購入するという手もあったのですが、Surface Pro Xは少々お高いですし、中古のARM Windows機はさすがにパフォーマンスが…。

Macbook Air (または Pro)も少々お高く、今年メインマシンの中身（CPU+マザーボード+メモリ+SSD）を8年ぶりに刷新した価格すら超えてしまうので却下です。Macのキーボードはキーストロークが浅すぎて許せないだろうなというのも(HHKB使い)。

ジニーエフェクト気持ち悪いなーとか（止めた）、CommandとControlキーが分かれているのはいいとしても ⌘ とか ⌥ とか読めないんですけど？とか、スクリーンショットのショートカットがcommand + shift + 3とか直感的じゃないよね？とか、画面はリモート接続で使うつもりだったのにプロトコルがVNCなのはちょっと…うちは無駄に4Kディスプレイ2枚なせい？でVNCめちゃめちゃ重くて有線LANですら使い物にならないんですけど？とか、Finderにアドレスバーがなくてメニューからなんですか？（メニュー遠い…マウスの移動量が…）とか、Finderから右クリックで新規文書作れないの？とか、アプリケーションインストール時にダイアログが出て、アプリケーションのアイコンをアプリケーションフォルダのアイコンにドラッグ＆ドロップしなければいけないの最初全く分からなかったんですけどこれは直感的なんですか？とか、かな漢字変換の未確定文字が明朝体なの気持ち悪い(Google日本語入力を導入)とか、いろいろ文句があるのはきっとまだ偏見が残っているのでしょう。

で、とりあえず、CrossOver for Macを評価してA5:SQL Mk-2を動作させてみました。…が、UX的にこれは酷いなーと。localhost以外への接続だとなぜか固まるとか、SQLエディタで文字を入力しているだけで固まるとか、CrossOver for Macの問題かWineの問題なのかRosetta 2の問題なのか、どこに問題があるのか判別できませんでした。MacOSや、CrossOver for Macのバージョンアップで解決してくれればいいのですが…。あと、 高DPIに対応していなくてフォントがカクカクになってしまうのがちょっと悲しいですね。それと、ショートカットキーが利かないと思ったらCommandキーではなくてControlキーでした。

…なんとなくですが、ショートカットキーとか×ボタンの挙動とか、WindowsのアプリケーションがMacのアプリケーションとして動くというより、Macの中にWindows環境があるといった動き方ですね。

なお、A5:SQL Mk-2自体のネイティブ対応ですが、ちらと考えはしたものの、

1. GUI全部作り直し（100画面以上ある）
2. カラー構文表示できるテキストエディタコンポーネントがなさそう(Delphi FireMonkey で動作するもの)
3. Windows APIをガシガシ叩いている(ER図はGDI+に依存してるし…)

等の理由によりちょっとムリな状況です。

あとは、Sequel Ace評価してみました。A5:SQL Mk-2よりライトなツールでしょうか。あまり、高機能でなくシンプルなほうがわかりやすくていいのだろうか？とか思ってみたり。A5:SQL Mk-2もライト版作ってみるか？とか（いる？）。Macは(Linuxもだけど)Control+SpaceがOSに抑えられているので、Escapeキーで入力支援が働くのは良いかも。A5:SQL Mk-2はユニバーサルデザイン的な考慮からCtrl+Space以外にもF4で入力支援を利かせていたけれど Esc に変えようかなと思ってみたり。

当初使い勝手の面や、いろいろアプリケーションが動かないとか、持て余し気味だったのですが、最近ようやくdockerがベータ版で対応し始めたり、PallarelsがMicrosoftと協力してARM Windows動くかも？とかウワサみたいなものがあったり…とりあえず、MicrosoftさんからARM Windowsのライセンスが販売されるようになると嬉しいです。

小学２年生になった子供たちが学校で九九を勉強し始めているみたい…ということで思いつきで「九九 計算尺」を作ってみました。九九の範囲内で整数の掛け算だけできる計算尺のペーパークラフトです。

PDFはこちらからダウンロードできます。

印刷用プログラムはDelphi製でgithubから３条項BSDライセンスで公開中です。

PDFまたは印刷用プログラムからA4サイズ横で印刷したら、以下の図に従って切りとって組み立ててください。精度が必要なのでハサミよりはカッターの方が良いでしょう。少し厚めの紙に印刷できると扱いやすいかもしれません。

本体は点線で山折りにし、のりしろの部分を折った下側に張り付けてふくろ状にして、中にスライダを差し込みます。

完成すると次のようになります。

使い方

かけられる数の▼の下に数字を合わせます。かける数の上の数字を読み取ると答えになります。

例）３×５＝１５ の場合

…今時親御さんでも計算尺とか知ってる人はどのくらいいるのだろうか…。

これまで、自分は「ジオメトリ」というものをよく知らなかったのですが、お仕事の関係上これからジオメトリ関連をよく扱うことになるので、A5:SQL Mk-2 のジオメトリ対応させていきます。

とりあえず、PostgreSQL(PostGIS)のGeometry型対応です。…なんか最近はMySQLでもジオメトリ対応している？？？。

Version 2.15.0出したばかりですが、Version 2.15.1でGeometry型対応をちょっと入れます。

Geometry型はユーザー定義型として、バイナリデータ型として扱われます。このままデータを取得すると、OpenGISのWKB形式(HEX表現)になってしまうのですが、これをA5:SQL Mk-2側で解釈してOpenGIS のEWKT形式（ ST_AsText() 関数で得られる形式…多分）で表示するようにします。

本当は、地図も同時に出せるとよいのだけれど、それはもう少し後になると思います。

A5:SQL Mk-2 Version 2.15.0 をマイクロソフトストアで配布し始めました。Vectorはもうちょっとかかるようです。

でさっそく不具合というか制限というか、どうしようもないのでわかってリリースしたのですが、A5:SQL Mk-2 Version 2.15.0のテーマ機能と高DPI環境はあんまり相性がよくありません。

テーマ機能は、見た目を変える機能で、Windows標準のコンポーネントをかっこよく（多分）見せる機能です。

一方、高DPI環境はこれまでのWindowsでは、96dpiを前提としていたフォントサイズをそれ以上(144dpiとか192dpiとか)とすることで4Kディスプレイなどで、文字や画像(用意した場合)をきれいに表示する機能です。（なお、A5:SQL Mk-2の高DPI対応では画像はこれまでのものを拡大表示しているだけです。）

で、高DPI環境で、テーマ機能を使った場合なのですが、どうも、ウィンドウのタイトルバーの高さが高くなりすぎてしまう関係上、ダイアログボックス等で、高さが足りなくなって一部ボタンが見切れてしまうようになってしまいました。

上の例ではかろうじてOKボタンが見えているものの、ダイアログによってはボタンの判別がつかない場合もあるようです。これは、利用しているライブラリの仕様上、修正が難しいと考えています。Version 2.15系では、高DPI環境下ではテーマ機能は使わないほうがいいかもしれません。

A5:SQL Mk-2で絵文字を使うと、こんな風に表示されます。

世の中にはカラー絵文字というのがあるそうで、WindowsではDirectDraw(DirectWrite)を使うとカラー絵文字が使えるらしい。何となくやってみたいなあと思い、テキストエディタコンポーネントをちょっと修正してみました。

カラー絵文字は表示されたものの、行番号が表示されないし、文字がちょっと見切れている。スクロールすると文字が消える…。文字描画だけをDirectWriteに変えただけではだめそうだ。どうやら、GDIとDirectDrawを共存というのは難しいらしい。グラフィック全ての描画をDirectDrawに切り替えないといけないようだ。

テキストエディタコンポーネントの描画をすべて修正するのは難しいし、この修正は当面リリースできなさそう?。

A5:SQL Mk-2のERエディタでは、これまでリレーションシップの線は最大でも「横線-縦線-横線」又は 「縦線-横線-縦線」 など、３本の線までしか対応できていませんでした。これまでも、もっと自由に線を引きたいとのご要望は受けていたのですが、なかなか大変で実装できていませんでしたが、Version 2.15.0 beta 23でようやく対応してみました。

このモードはリレーションシップの線を選択して右クリックして、線種から「自由結線」を選択することで利用することができます。

最初は直線で表示されますが、直線の中間地点にあるグレーのハンドルをドラッグすることで頂点を追加できます。

頂点を削除するには、頂点の赤いハンドルを選択して右クリックメニューから「頂点の削除」を実行すると削除できます。

なお、サブモデルの機能を使えば、あまり複雑な線を引かなくとも（自由結線モードを使わなくとも）それなりにER図を描くことができます。あまり複雑な線を描くと、かえって分かりづらくなったりすると思います。https://a5m2.mmatsubara.com/tips/er_submodel/

90年代とか昭和とか言われるA5:SQL Mk-2のデザインセンスですが、テーマ機能を使うととりあえず、ぱっと見の見た目をマシにすることはできます。

ただ、このテーマ機能はやや重い機能であるとか、高DPIで使うとタイトルバーが細くなってしまうとかいろいろ問題があるため個人的にはあんまり好きではありません。

テーマ機能を実装するより前から、テーマ機能とはべつに「テーマカラー」機能を実装していました。テーマ機能がデフォルトの「Windows」であるとき、この「テーマカラー」機能が使えます。テーマカラーはA5:SQL Mk-2の背景色（通常は灰色の部分）を決定する機能です。これを変えるだけでもモダンとまではいかなくとも、そこそこ印象は変わるかもしれません。

今回、Version 2.15.0 beta 19から、このテーマカラーのデフォルト色を灰色（システムのボタン表面色）から「薄灰桜」というやや淡いピンク基調の色に変えてみました。（A5:SQL Mk-2のテーマカラーの色は日本古来の色の名前を使っています。）

今までのデフォルトのテーマカラー

新しいデフォルトのテーマカラー（薄灰桜）

どうでしょう？

なお、使用中の環境を更新していてテーマカラーが変わらないばあい、オプションダイアログの「全般」タブから選択することができます。

偏差値 46の現状を打破すべく、Delphi用ライブラリであるDMonkey(ECMAScriptエンジンのサブセットライブラリ)のUnicode対応版をGitHubにアップしてみました。

https://github.com/m-matsubara/DMonkey

ECMAScriptといっても、やや古いECMAScriptの仕様なので、現状どの程度の需要があるのかはよくわからないですが。

このライブラリは以前、A5:SQL Mk-2をUnicode対応したときに一緒にUnicode対応したものです。

元々、Version 0.3.9 をベースにUnicode化してA5:SQL Mk-2に組み込んでいましたが、GitHubで公開するのに合わせて、最新のバージョンである、Version 0.3.9.1に追従しています。（何か不具合仕込んでしまっていなければいいのですが…）

また、README.mdにも記載していますが、Unicode化に伴って廃止・追加されたオブジェクトやメソッドがあります。

これまでA5:SQL Mk-2のソース管理は自前で建てたgitサーバーを利用していました。GitHubがプライベートリポジトリを無償で使えるようになったというのでどうしようかな～と思っていたのですが、思い切って載せ替えてみることにしました。

gitリポジトリの移行は以下のコマンド(Qiitaより引用)

何かトラブルがあるかと思ったのですが、あっけなく完了しました。

あんまり今まで知らなかったのですが、GitHubにはContribution Graph（通称芝生）というのがあり、コミット数に応じて、日ごとのマス目がどんどん緑色に染まります。自分のは以下のような感じ。

すごい人はほんとに芝生のように青々としているみたいですが、自分のはそこまでいかないですね。これだけ見るとまるでサンデープログラマです。むしろ、会社休んだ日がバレてしまうのではないかといった感じ。まあ、平日は家事・育児が忙しいので。（子供たちが小学校に入ったら途端に忙しくなった。）

ただ、これまではgitサーバーは補助的に使っているだけで、ソース管理は、ビルドするごとにソース全体をzipで固める運用（そしてOneDriveにバックアップ）をしていました。なので、gitサーバーにコミットしなくても全然問題なしで、実際gitサーバーにpushするのが面倒で全然pushしていない期間もありました。

実のところ開発に使っているフォルダとリリースに使うフォルダも分かれていませんでした。これからはこれも改めて、開発フォルダとリリース用のビルドフォルダを分けて、GitHubにpushされたソースをリリース用のフォルダからpullしてビルドするように、zipで固める代わりにビルドバッチ内でタグを打つようにします（しました）。これでGitHubへのpushもまじめに行うようになるはずです。（行わなければなりません。）

…ところで、FindyというサイトがGitHubの開発状況を見て「スキル偏差値」なるものを出してくれるのですが…自分の偏差値が「４６」…マジですか？、標準以下ですか？。頑張っているつもりなのだけれど…。

プライベートリポジトリだとダメなのかなあ？。こちらのサイトではプライベートリポジトリも審査の対象となるようなことが書いてあるのだけど、あまりプライベートリポジトリは重視されないんですかね？。

この記事は、Delphiの最新バージョンである、Delphi 10.3ではなく、Delphi 10.2について書かれています。新しいバージョンでは状況が異なる可能性もあります。

最近4Kディスプレイを買ったのですが、これまでも4Kディスプレイ買おうかなと考えたことはありました。しかし 「Delphiの開発環境(IDE)の表示、どうなっちゃうんだろう？」 との不安があり、躊躇していました。

問題はDelphiはフォームの設計段階では、ウィンドウやコンポーネントの位置・サイズ指定をピクセル単位で行うことです。このため4Kディスプレイなどでは、「フォームデザイン」の画面が小さくなりすぎて支障をきたさない？などと考えていたわけです。うまくフォームデザインの画面を拡大表示してくれるのでしょうか？。でも、Delphiで使うコンポーネントはデザイン画面でも実際に動作するのがウリのはずです。また、拡大縮小しなければならないプロパティはLeft, Top, Width, Heightだけとは限りません。それとも、TFormクラスにある、PixelPerInchプロパティが何か関係しているでしょうか？。設計時と異なるDPI環境ではこの PixelPerInch プロパティとの比率に従い画面サイズを調整してくれるのでしょうか？。複雑なDPI変換のルールで、動作に支障をきたさないでしょうか？。

…４Kディスプレイを購入し、実際試してみたところ…そもそもDelphiのIDEは、そもそも高DPI環境に対応していませんでした。192DPI(200%のスケーリング)にしたところ、がっつり200％にスケーリングされます。全然フォントとかきれいになりません。

テキストエディタもカクカクフォントです。

ちょっと残念ですが、あえて高DPIに対応しないおかげでDelphiの開発環境は96DPI前提のまま ピクセル単位で 開発（設計）できるのですね。 上述したような画面設計をピクセル単位で行うことに由来する問題・懸念は発生しません。

ちなみに、、、高DPIに対応しないアプリケーションを無理やり高DPIに対応させて実行する方法があります。

「ダイジョウブ・ダイジョウブ」「イケル・イケル」と唱えながら、以下の設定を変えます。(Windows 10 1903の場合)

該当の実行ファイル(DelphiのIDEはbds.exe)のプロパティを開き、「高DPI設定の変更」ボタンを押します。

「高いDPIスケールの動作を上書きします。」にチェックを入れて、下のプルダウンから「アプリケーション」または、「システム（拡張）」を選択してOKを押します。

「アプリケーション」の設定では以下のようになりました。

フォントはきれいですが、開発中の画面は指定値通りに小さくなります。ただし、タイトルバーやメニュー・非ビジュアルコンポーネントのフォントは大きくなります。あまりこのまま開発してよさそうな気がしません。

「システム（拡張）」の設定では以下のようになりました。

何か微妙にところどころフォントがきれいになるのですが、基本的にカクカクフォントです。あと、デバッグ実行されたアプリケーションまで「システム（拡張）」の設定が引きずられて96DPIで実行されてしまうようです。

DelphiのIDEはやっぱり高DPIに対応させないほうがよさそうですね。

そもそも、Delphiが画面の位置やサイズ指定をピクセル単位で行ってしまっているためだと思うのですが、DelphiのIDEは高DPI化の難しいアプリケーションのようです。最新のDelphi10.3は試していませんが、仕組み上難しいのかなあとも思います。Delphiで開発するアプリケーションは高DPI対応は問題ないのですがね。