macOSのファインダー操作。Gitのリポジトリを何処に作ったか確かめたいときがある。たとえば次のようなフォルダ構成がある。
ここでcommnad+shift+.(ピリオド）キーを押す。これは隠しファイルを表示する、というmacOSのコマンド。
これで.gitフォルダーが「denpyou-jirou」に作られていることがわかる。もとに戻すときは、もう一度commnad+shift+.(ピリオド）キーを押す。
ちなみにここに表示されている「.gitignore」ファイルはコピペで別のリポジトリに移動させることもできる。
ターミナルアプリを使って、ls -alコマンドで見てもいい。
ターミナルアプリを起動するのが面倒な方はcommnad+shift+.(ピリオド）キーがお勧め。
ループを記述するには、For、Repeat、Whileがある。たいていのループはどの構造でも書ける。どれにするか迷う。そこでマイルール：
できるだけForを使う理由の一番は、繰り返し回数の上限がループに入る前から決められていること、である。repeatやwhileでは、条件設定をミスっていると無限ループになって開発効率が悪くなる。
で、この習慣に従うと、ループの回数を事前に取得するのが当然になってくる。デバッグでこの回数を見れば、変な結果を返している場合は、まず繰り返し回数をチェックしてゼロとか意外な数値が入っていないか確認する。トレースする場合でもデバッグ中だけ繰り返し回数に小さな数字を代入してループの動きを見ることも容易だ。
ただし、何が何でもforにする、ということではないことに注意。
定型文のようにwhileを使っていて、そのコードをコピーして使う場合、ほかと同じ構造になっていると可読性がいい、のでこの場合は「どっちでもいい」ことにはならず、理由があってwhileを使う場面になる。理由が言えるのであればforじゃなくてもいいよ、ということだし、理由が言えなければforで書いてね、ということ。
連休前に注文していたMac Studioが入荷した。Mac miniよりも速いはずなので負荷の高いサーバ用途に使えるかどうか試してみようということで。早速梱包を解いてみる。
箱の上面にハンドルがついている。円筒形の黒いMac Proと同じだ。
なんと、箱が左右に傾いて開口部が開く。おかげで本体を楽に取り出せる。
本体を取り出すと、底にはケーブルが、いつものようにボール紙に巻いてある。
起動して、4D v19 Serverを動かしてみた。4DはまだM1ネイティブ対応ではないためか、それほど速さを感じない。macOS上で行う圧縮・解凍とかブラウザのアップロードは速い。運転音は無、まったく気にならない。
4DがM1ネイティブ対応になってくれれば、と思う。
「WEB+DB PRESS vol.127」（以下、wdp127）にリファクタリングの話があったので読んでみたら良かった。
https://gihyo.jp/magazine/wdpress/archive/2022/vol127
知らない単語が出てきたのでメモしておく。
□ 凝集度（cohesion）
□ 結合度（coupling）
調べてみると、語源は1979年あたりにヨードンが提唱していたらしい。
□ DRY（Don’t Repeat Yourself）
コードの最適化、なんでもDRYというルールがあるそうだ。
プログラミングしていると、同じようなコードを何度も書くとき、共通化できるのでは？と考える。あちこちに書いておくと、あとでそこに修正が生じた場合にあちこち直さなくてはならないため不便だし、処理が同じならモジュール化すべきだという考えだ。
wdp127では凝集度について、論理的凝集は避ける、ようなことが書いてある。要はフラグを使った関数内分岐を避けよ、という意味と理解した。ウチでは同じような意味で「多機能関数はダメ」というルールがある。
結合度については値は引数で渡す、ようなことが書いてある。要はグローバル変数は避けよ、という意味と理解した。ウチでは「関数の中はローカル変数だけを使う」と「グローバル的な変数にはゲッターセッターを用意して関数を介して取得する」というルールがある。ただし例外として、画面に一覧を表示する際のフォームオブジェクトはグローバル参照をしていいというルールもある。画面に表示する情報についてゲッターセッターをすべて用意するのはあまりにも面倒だ。フォームオブジェクトは名前付のルールでわかるようにしている。
ウチでは上記のほかに、
forやifの構造が３つ以上出現する場合は、さらなるモジュール化を検討せよ、という意味だ。
仕様がケース分岐しているのであればコードも分岐している、のがフツーだ。入り口から分岐させて、中に共通処理を見つけたら共通モジュール化する、のが良い。
できるだけ１行で書く、というコードはダメ。if文の中に関数を記述したり、引数に関数を記述するのはわかりやすいNGだ。デバッグする時にたとえばforループが何回回るのかは重要な要素だ。上手くいかないときは0回の場合が多い。これをデバッグするには繰り返し回数を見れば良いのだが、大体はなんかの関数の戻り値である。これをfor($i;1;myFunc())のように書いてしまうとmyFunc()の戻り値を見たくなる。$count:=myFunc()とか記述して$countの値を見ることになる。それなら最初からそういうコードにしておけば良い。
上記はソース内部の記述だが、表面的な仕様でもデバッグに便利な機能を実装しよう。あるテーブルの中身が見たいような機能は言われなくても作ってしまう。デバッグでよく使うツールであればプログラマは便利になる。そのままリリースして、ユーザに「削除して」と言われてから「隠す」ようにすればよい。
まだ語り尽くせないので、また思いついたら続きを書く。。。
これまで4Dでのアプリ開発はストラクチャーファイル（.4db）を作ることだった。ストラクチャーファイルはバイナリファイルだ。4Dで開けば中身を見ることができるが、外部からは何が書いてあるのかわからない。このためgitのようなバージョン管理システムでソースの差分を管理することができなかった。
4D v18から「プロジェクトモード」という形で保存できるようになった。プロジェクトモードではフォームもメソッドも「Sources」というフォルダにテキストファイルで保存されている。これらのテキストファイルをテキストエディタで修正すると、変更内容が4Dのフォームエディタやメソッドエディタに表示される。外部からテキストファイルを修正すると「ストラクチャー」に変更内容が適用されるのだ。
従来からあるストラクチャーもサポートされていて、従来通りの開発方法を選んでソースをバイナリ形式で保存することもできる。こちらは「バイナリモード」と呼ぶ。新規プロジェクトを始めるとき、開発者はバイナリモードかプロジェクトモードのどちらかを選ぶことになる。バイナリモードには「プロジェクトに書き出し」を実行してプロジェクトモードに書き出すことができる。v17以前のプロジェクトはこの方法でプロジェクトモードに移行する。プロジェクトモードからバイナリモードに変換することはできない。
筆者がプロジェクトを推奨する理由はいくつかある。
１）メソッドを生成したい
２）フォームを生成したい
３）gitを使って修正箇所（差分）を知りたい
これまで１）はプロジェクトメソッドであればやっていた。JCL4D（当社ライブラリ）を使えばテーブル定義のテキストファイルからプロジェクトメソッドを生成できる。ただしオブジェクトメソッドやフォームメソッドを生成することはできなかった。熱望していた２）はほぼほぼ実現は無理、３）もあきらめていた。
2014年にパリで開催された4D Developer Summitでに参加した際に、「フォームジェネレータを作りたい、使えるコマンドはないか」と質問した時は、そのようなコマンドの実装計画はない、と回答された。2020年のv18でフォームは生成できるようになった。対応が早いことに驚く。
以下、バイナリモードを使ってみたところ、いくつか注意事項があったのでメモしておく。
ウィザードを使ったフォーム生成機能がない。ユーザモードを使ってデータを確認するときは不便だろう。もともとフォームを自動生成する仕組みを作るつもりだったので、まあいいかという感想。半年くらいかけてJCL4DにFormGeneratorを作成した。これを使えばフィールド定義ファイルからテーブルを生成、続けてメソッドとフォームを自動生成することができる。
実行モードでは適用される。設定がうまくできているか確認しづらいので注意。
Finder/Desktop上でファイルの入っているフォルダを表示すれば変更が適用されたりする。
ソースはテキストファイルなので、開発者が各自手元で修正してアップしてcommitすることになる。
これ以外にも注意点や制約がありそうだが、気付いた時点でまたブログを追加する。