投稿者「wt」のアーカイブ

2020は干し柿好調

2020 干し柿についてのメモ

10月になって庭の渋柿にオレンジ色が差してきた。早めと思ったが、たくさん生っているので順次収穫していかないと後工程が押してくるため収穫開始。今年は熟すのが早い印象。グズグズしているとヒヨドリに突っつかれてしまう。まずは30個くらいとってみて皮むき。

10日くらい干したら食べれた。いつも通り甘く、相変わらずタネは多い。

皮むき

水につけると乾きが悪くなるため洗わない。鉄の包丁は黒くなるのでセラミックを使う。スズラン紐で結んで、一本の干し竿に15個から20個引っ掛けて吊るす。

外干し

干し柿は戸外の物干しに引っ掛けておいて乾かす(外干し)。ずっと部屋干ししていると風が当たらないので乾きが悪く、室温が高いため腐りやすい。理想的には昼も夜も外干しが良い。くれぐれも雨に当てないように。濡らすと台無しになる。

2020.10.24

台風被害、鳥獣被害

思えば一昨年は台風被害、昨年は10個くらいしか取れなくて、干している最中にヒヨドリに全部食べられてしまって...

今年は台風被害は免れた。なぜかヒヨドリの被害がない。よしよしと思っていたら干している最中にやられた。おそらくアライグマだ。干して甘くなったやつだけ10個以上食べてった。竿を引き摺り下ろして、まだ乾いていないのも被害。夜中の12時ごろから1時間くらい目を離していた、その15分くらいの間に。

夜ぼしはNG

猫のかごを出してきて、これなら取られないだろうと、夜も外干ししておいたら、再びやられた。檻の中に手を伸ばしたのだろう、干し柿に届くようだ。12個くらい食べられている。夜はヤバイ。毎晩取り込むようにした。昼間はやられない、これで大丈夫だ。


11月に全量収穫

もうオレンジ色を通り越して赤みが出てきている。これ以上木の上においておくと熟してユルユルになって、皮むきができずに干し柿にならなくなる。大量に収穫、皮むいて、吊るす。朝外に出して、夕方家の中に引き込む。

夜このままにしておくと、下の方の甘くなったのを取られる


熟柿(ジュクシ)

皮むきを先送りにしていると柿は熟してくる。熟すと身がユルくなって干し柿にはできない。そのうち熟柿という状態になる。これはもう中身がユルユル。皮はブドウの皮のように薄くなって、見た目は赤みが出てきている。渋は、完全に抜けている時もあればまだ少し残っている時もあるがいずれも食べた直後は甘い。渋は後味にやってきて舌に残る。食べ終わるまでわからない。

11月12日、皮むき完了。この時点で330個。すでに食べちゃった分、クマに食べられた分、鳥にやられた分を考慮すると400個近く収穫できた事になる。10年くらい前に300個、という記録があったが、今年は記録更新。

柿の木1本から330個収穫

来年も豊作でありますように。

何年か収穫が思うようにならなかったため、鉢で育てていた2本の若い木(7、8年もの)を2年ほど前に庭植えした。タネから実生で増やしたやつだ。今年1個だけ花をつけたので来年あたり実がなるかもしれない。

notarizeで失敗 20201022


notarizeで、またもや失敗、1048エラー。9月にはできたのに...。おそらく契約関係の承認が必要になったのだろうと、Apple Developer Connectionにアサインして、Membershipを見ると、一つあったので承認。それでもまだ1048エラー。次のようなメッセージが返された。

Package Summary:

1 package(s) were not uploaded because they had problems:

/var/folders/7n/535dkwvn2hs_kttq4x17npg40000gr/T/6FA147A3-542B-4559-B2EA-7F446BA71777/Untitled.itmsp – Error Messages:

You must first sign the relevant contracts online. (1048)

2020-10-22 21:05:09.976 altool[8484:1281657] *** Error: You must first sign the relevant contracts online. (1048)

このエラーメッセージにはいつもパニックになる。気を取り直して、ネットで検索したらApple のサポートページがあった。

Notarization error 1048

よく見ると、developerサイトと、appstoreconnectサイトにペンディングのアグリーメントがあるかチェックしろ、と書いてある。appstoreconnectに行ったらペンディングがあったので承認したらnotarizeは成功。

あとでメーラーを見てみたら、次のようなメッセージが来ていた。

このメールに反応していれば問題は起きなかった、はず。

4Dのプロセス変数にゲッターセッターを記述するのはもう古い?v18で提供されたClassesのFunctionが使えそう。

プロセス変数とはプロセス内で参照可能な変数のこと。プロセスというのは同じマシンならNew Processなどで区切られたメモリー上の作業空間とでも言えばいいか。Client/Server環境ではサーバサイドで実行などにより実行マシンが違えば作業空間は異なるので別プロセスだ。別のプロセスの変数はそれ用のコマンドを使わないと参照できない。

人それぞれ違うと思うが、ウチの開発スタイルではプロセス変数は次の2種類がある。

(1)フォームオブジェクトに割り当てるためのプロセス変数
(2)プロセス内でグローバルに参照するために用意する主として制御用のプロセス変数

(1)は4Dの仕様上必要な変数。フォームが表示されている間はメソッドからフォームオブジェクトを参照したくなるはずで、メソッドが終わってもフォームがある限り解放されないプロセス変数であることが合理的だ。個人的に、次のように名前を付けている。

・ vPL01_btnOK:PL01というフォーム上の「OK」ボタンという意味。ボタンの場合はプロセス変数に代入することはない。オブジェクト名を参照しているだけ。

・ vPL01_lstPL:PL01というフォーム上の「lstPL」リストボックスという意味。vPL01_lstPL_IDやvPL01_lstPL_NAMEなどを列として定義、DBのPLというテーブルから持ってきた値を表示する。プロセス変数はプロセス開始時に領域が確保されるが、リストボックスはOnload前は参照できないので注意。

・ vPL01_txtPL_NAME:PL01というフォーム上の「PL_NAME」フィールドで、DBのPL_NAMEから持ってきた値を表示するためのプロセス変数という意味。

変数名とオブジェクト名は別の名前をつけることもできる。どちらもプロセス開始時に領域を確保されてしまう。特に困ったこともないので「オブジェクト名と変数名はいつも同じ」にしている。同じ値のオブジェクトには同じ変数名をつければどちらも同じ値が表示される。が、別々の名前をつけて値はコードで代入し直す方が主流だ。

(2)は、フォーム上に表示されない、プロセス内の制御用の変数。例えばよく使う変数としては、ダイアログを表示するメソッドの場合にどのフォームから呼ばれたかを示すモードのような変数「vPL01_varMode」とか、一覧で選択されていたIDを詳細画面で保持するための変数「vPL_varPL_ID」とか、印刷時に現在のページ数を印字するための変数「vP01_varPageNr」など、がある。

このような変数にはいわゆるゲッター/セッターを用意して直接参照はしないようにする。フォームオブジェクト以外は、基本的に変数はローカル変数にすべきで必要な関数に引数で渡して使う、という考え方がまずあって、オブジェクト型の変数が無かった時代は多くの引数が必要になってしまって面倒すぎるのでグローバル変数を使いたい、という時代背景がある。例えば「vPL01_varMode_get」と「vPL01_varMode_set」である。次のように使う。

//PL01_DefInit
・・・
C_TEXT(vPL01_varMode)
・・・

//vPL01_varMode_get
C_TEXT($0)
$0:=vPL01_varMode

//vPL01_varMode_set
C_TEXT($1)
vPL01_varMode:=$1

//PL01_SetContorolsValues
・・・
//新規追加モードの場合、削除ボタンは非表示にする
C_TEXT($mode)
$mode:= vPL01_varMode_get
if ($mode=“add”)
 OBJECT SET VISIBLE(*;”vPL01_btnDelete”;False)
end if
・・・

このように記述していると、メソッド内にはフォームオブジェクト以外のプロセス変数が現れなくなる。このやり方は、まだ4Dに不慣れな頃に師匠から伝授されたものだ。初めはなんでこんな面倒なことをするのだろうと思っていたが、今でもこのやり方を踏襲している。実はこの種のプロセス変数はそんなに多くない。メソッド数が増えてしまうが、たいして手間ではないし、このようにすることでデバッグタイムが少なくなっていると感じている。教えてくださった先輩に感謝!

この方法の欠点としてメソッド数が増えてしまうと書いた。わずか2行のコードのために新しいメソッドを作る手間も感じていたがv18で改善された。ClassesのFunctionを使えば、オブジェクト表記の延長で「vPL01_varMode.get」などとメンバー関数を記述できる。そしてなんと一つのメソッドエディタ内に複数のFunctionを定義してゲッターとセッターを記述できるようになるのだ。

Laurent Esnault氏のセッション。今年の4D Summit 2020はオンラインで無料。英語がダメでも画面見てれば大体わかる素晴らしいデモに感謝。その内容に感激!4Dライフが大きく変わること必至。

まだv13のプロジェクトもあるが、コーディング規約を改訂するときがきたようだ。

4DのDrug and Drop

4D Drug & Drop

ひとつの画面に複数の画像を表示する仕組みを考えていた。画像は外部ファイルを想定、多くて10個くらいあるのだが、要望としては代表的な画像を2個登録したい、ということだった。例えば画像は2個と限定してピクチャー変数を2つ配置しておけば、ドラッグ&ドロップを2回やれば画像登録ができる。操作も実装も簡単だ。しかしプログラマーとしては、3個以上の画像がありうるのに2個に制限して良しとするのは敗北感がある。

そこで考えた。リストボックスがいいんじゃないか?リストボックスなら画像をいくら追加しても大丈夫。行が増えていけば勝手にスクロールしてくれる。画像の数を制限しなくて済む。画像は別テーブルに保存すれば良い。

いつものようにリストボックスの上に[+]と[ー]のボタンを置いて、[+]クリックで表示されたダイアログにピクチャー変数を配置してドラッグ&ドロップしてもらって、という仕様で実装した。

これだとダイアログボックスを開いて閉じるのが面倒。もともとの要望の通り、ピクチャー変数を2個、配置しておけば、ドラッグ&ドロップを2回やれば画像登録ができる。その方がユーザは簡単だ。同じように簡単な操作で複数の画像を登録する方法はないのだろうか?

リストボックスに画像をドロップすればいいのでは?

リストボックスに画像をドロップしたら行が増えていくようにすれば操作性は悪くない。ドロップのたびに行を追加、削除するときは[ー]ボタン。増やしたり減らしたり、縦スクロールなら実装も簡単そうだ。

ただリストボックスに画像をドロップしても標準的な機能では受け取ってくれない。リストボックスのOnDropイベントにコードを書くことになる。OnDropで配列要素を増やして、画像列に取得した画像を代入すればいい。と、ここまでわかったところで気がついた。一般に4DでDrug&Dropをい実装する場合は、フォームオブジェクトが勝手に処理してくれるからコードを書く必要がない。マニュアルサイトを見ても、イベントを取得したあと、ドロップされたコンテンツをどうやって受け取るか、よくわからない。

とりあえずリストボックスにイベントハンドラを書いて。

ドロップされた画像はドラッグ&ドロップ専用のペーストボードから取得するそうです。

GET PICTURE FROM PASTEBOARD($picture)

OnDropで呼ばれるコードはこれ。

リストボックスに行を追加したり、自動スクロールさせたり、ついでにドロップされたファイルのパスを取り出したり、している。

ドロップされた直後に行を選択して、自動スクロールさせていてる

4D macOSでプロジェクトのパッケージ化をやめる

いつも使っているのがMacBook Pro(13-inch 2018)なので、4DのプロジェクトもmacOSで開発している。Windowsで動かす場合もコーディングはmacOS。Windowsを使うのはたまにフォームを調整する時だけだ。最近わかったことだがメイリオフォントを使うとWindowsとほぼ同じレイアウトになる。例えばリストボックスの列幅にはソートマーク表示用に余裕を持たせるなど、少しのケアで調整はいらなくなる。要はmacOSとWindowsで同じフォントを使えば良いのだ。MSゴシックやMS明朝もあるけどこちらは試していない。

さて本題。4D macOS版でプロジェクトを作ると、ストラクチャファイル(「.4DB」ファイル)は「.4dbase」という拡張子がついたフォルダの中に生成される。この. 4dbaseフォルダがmacOSの「パッケージ」だ。パッケージは特殊なフォルダで、アイコンをつけたり、ダブルクリックで中の所定のファイルを開くことができる、macOSが提供してくれる便利?な機能だ。

プロジェクトフォルダはパッケージなので選択しただけでは中は見えない

例えばmacOSのアプリケーションフォルダに並んでいるアプリはダブルクリックすると起動する。アイコンもついてる。実行ファイルのように見えるが実態は「.app」という拡張子がついたパッケージ。多数のファイルで構成されているアプリでもパッケージでまとまっているためにスッキリしている。アプリを起動する時、アプリケーションフォルダを開いて、そこに並んでいるアプリのフォルダを開いて、その中のアプリ本体を見極めてダブルクリックするよりは、アイコンのついた.appをダブルクリックした方が楽だろう。1階層ほじらなくて済む。

4Dのパッケージに話を戻そう。この.4dbaseのアイコンをダブルクリックすると4Dが起動してプロジェクトが開く。4Dでアプリ開発の続きをやるだけなら1階層ほじって.4DBファイルをダブルクリックする必要はない。

リリース時にはストラクチャファイルやデータファイル(「.4DD」ファイル)を操作することになる。ストラクチャファイルを取り出して圧縮したり、開発用のデータファイルを本番データに入れ替えてから圧縮したりする。プロジェクトのパッケージを右クリックして「パッケージの内容を表示」を実行する。ウインドウに表示された.4DBファイルを選択して、ドラッグしたりして移動させてから圧縮する。

パッケージを右クリック

元のフォルダに戻るときはウインドウタイトルを右クリックしてプルダウンメニューを表示させて、階層が1つ上のフォルダを選択する。このようにmacOSで作業するときはパッケージの中に入ったり出たりしている。

ウインドウタイトルを右クリック

これってもしかして面倒臭い?

Windowsに持っていくとパッケージはフォルダとして認識されるし、そもそもパッケージ化が必要なのかを自問してみると、

1)パッケージをダブルクリックしてプロジェクトを開くことはしない
 → パッケージに中の「.4DB」ファイルをDockの4Dアイコンにドロップして開いている。ちなみに現在のDockにはv15からv18までの4Dと4D Serverが並んでいる。

2)「Resources」フォルダ、「WebFolder」フォルダ、「Components」フォルダの中身を操作することは多い

3)データファイルを操作する
 データが巨大なために「.4DD」ファイルを差し替えてから圧縮するプロジェクトもある。

4)いつものことだが頻繁にリリース作業を行っている
 ビルドしてリリースするものもあるが、「.4DB」ファイルと「.4Dindy」ファイルを圧縮して送ることが多い。パッケージの中に入ったり出たりすることになる。

長年付き合ってきて名残惜しい気もするがパッケージは邪魔でしかないという考えに到達した。やめるのは簡単だ。パッケージについている「. 4dbase」という拡張子を削除するだけ。4D的には何も問題はないらしい。現にWindowsではこの機能は使えないし。

やってみたら快適だった。クリックするだけでプロジェクトフォルダに出たり入ったりできる。当たり前だけど。

普通のフォルダ

少しだけ弊害があった。プロジェクトフォルダがわかりにくくなったのだ。今まではアイコンがついていたので識別しやすかったし、パッケージの中は4Dの管理下にあるファイルでその外側は自分で入れたファイル、という境界をはっきりと意識できていたのが薄れてしまった。なるほどパッケージにも一利あったのだ、と思いつつも面倒が減ったからこれでしばらくやってみよう。