これでようやく満開の河津桜
伊豆河津では2月になると咲き始め、3月には終わっているはずの梅より早く咲く河津桜。梅はいつもより少し遅いくらいだが、こちらはかなり遅い印象。
ミザクラは早く花が咲く桜。実がつくのも早い。梅雨前には食べられる。
同じ日の梅。ウチで一番遅い梅。まだ蕾が多い。
投稿者「wt」のアーカイブ
やってることの分だけコードがある、のはフツーのこと。
「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 v18からはストラクチャーではなく「プロジェクト」
これまで4Dでのアプリ開発はストラクチャーファイル（.4db）を作ることだった。ストラクチャーファイルはバイナリファイルだ。4Dで開けば中身を見ることができるが、外部からは何が書いてあるのかわからない。このためgitのようなバージョン管理システムでソースの差分を管理することができなかった。
4D v18から「プロジェクトモード」という形で保存できるようになった。プロジェクトモードではフォームもメソッドも「Sources」というフォルダにテキストファイルで保存されている。これらのテキストファイルをテキストエディタで修正すると、変更内容が4Dのフォームエディタやメソッドエディタに表示される。外部からテキストファイルを修正すると「ストラクチャー」に変更内容が適用されるのだ。
従来からあるストラクチャーもサポートされていて、従来通りの開発方法を選んでソースをバイナリ形式で保存することもできる。こちらは「バイナリモード」と呼ぶ。新規プロジェクトを始めるとき、開発者はバイナリモードかプロジェクトモードのどちらかを選ぶことになる。バイナリモードには「プロジェクトに書き出し」を実行してプロジェクトモードに書き出すことができる。v17以前のプロジェクトはこの方法でプロジェクトモードに移行する。プロジェクトモードからバイナリモードに変換することはできない。
筆者がプロジェクトを推奨する理由はいくつかある。
１）メソッドを生成したい
２）フォームを生成したい
３）gitを使って修正箇所（差分）を知りたい
これまで１）はプロジェクトメソッドであればやっていた。JCL4D（当社ライブラリ）を使えばテーブル定義のテキストファイルからプロジェクトメソッドを生成できる。ただしオブジェクトメソッドやフォームメソッドを生成することはできなかった。熱望していた２）はほぼほぼ実現は無理、３）もあきらめていた。
2014年にパリで開催された4D Developer Summitでに参加した際に、「フォームジェネレータを作りたい、使えるコマンドはないか」と質問した時は、そのようなコマンドの実装計画はない、と回答された。2020年のv18でフォームは生成できるようになった。対応が早いことに驚く。
以下、バイナリモードを使ってみたところ、いくつか注意事項があったのでメモしておく。
□ 標準入出力フォームを生成する機能がない
ウィザードを使ったフォーム生成機能がない。ユーザモードを使ってデータを確認するときは不便だろう。もともとフォームを自動生成する仕組みを作るつもりだったので、まあいいかという感想。半年くらいかけてJCL4DにFormGeneratorを作成した。これを使えばフィールド定義ファイルからテーブルを生成、続けてメソッドとフォームを自動生成することができる。
□ スタイルシートが開発モードでは確認しづらい
実行モードでは適用される。設定がうまくできているか確認しづらいので注意。
□ 外部テキストファイルを修正した場合、アプリに反映するのに少し時間がかかる
Finder/Desktop上でファイルの入っているフォルダを表示すれば変更が適用されたりする。
□ リモートの4D Server上のソースやフォームを4D Clientで接続して編集することができない
ソースはテキストファイルなので、開発者が各自手元で修正してアップしてcommitすることになる。
これ以外にも注意点や制約がありそうだが、気付いた時点でまたブログを追加する。
4D Server v18をmacOS Big Surで運用中に発生した問題 2021年3月以降
4D Server v18.4をmacOS Bigu Surにインストールした後、運用中にトラブルに遭遇した。
4D v18.4のインストーラ「4D_v18.4_Mac_Japanese.dmg」をダブルクリックして起動。次のような画面が表示される。いつものようにマウントされたボリュームの4DのフォルダをApplicationsフォルダにドラッグ＆ドロップしてインストール。あとは4D Serverをドックに入れて起動するだけ。
この状態で運用していたらファイルアップロードに絡んで実装している機能でエラーが表示された。サーバ側で受信したファイルを所定のフォルダに移動しようとした時、MOVE DOCUMENTが失敗しているようだ。「ドキュメントが移動できません。」と表示されている。
これまで動いていた機能なので不審に思って、サポートに連絡。すると「インストールに失敗している」との回答が得られた。なんでも2021年３月にAppleがGate Keeperの仕様を変更したらしい。「dmgをマウントしたボリュームの「4D v18.4」フォルダごとドラッグ＆ドロップしないで、.appファイルを一つずつドラッグ＆ドロップしてコピーしてほしい」とのこと。
インストールが失敗しているか確認するには、アクティビティモニタで4D Serverをダブルクリックして、「開いているファイルとポート」をクリック、そこに表示される４行目が「/Applications…」で始まっているかを見る。インストールが失敗していると「/Private」で始まる。
「4D v18.5」でも同じ注意が必要。
【注意】
この問題が厄介なのは、MOVE DOCUMENTのようにサーバ側でファイルを動かすような機能を実行しないとエラーにならないこと。/Private状態でもDBへの読み書きなど、ほとんどのコマンドは動いてしまう。また、dmgを開いた時、インストーラの画面には上記の注意を促すメッセージは表示されない。