タッチバー搭載初期モデルのMacBookProではiPhone15をターゲットにできない

iPhone15 Pro Maxを0.5秒でポチったわたしなのだけど

まさか、手持ちのMacBook ProでiPhone15をターゲットにして開発できないとは思わなかった

まぢか、そろそろM系MacBook Proにしないとダメなのか

今でも全然使えるんだけどなぁ、、、

その辺のWindowsより断然サクサク動くので、VSCode入れてJava系の開発環境にしている

以前Swiftを学びながら６日で作ったソリティアも、

全然問題なくXCode14で動く

しかし、XCode15には出来ないのだ、、、

うーん、今年はあれこれお金を使ったので、

来年か、再来年かなぁ

M5出るまで待つかなぁ、、、

ATL

随分前に、COMを使って、

Oracle OO4Oを模し、中身はADOと言うものを作った事がある

そもそも、OO4OはCOMモジュールなので、

COMなどはVB(VB6)で作れば良いじゃ無いかと思っていたのだけど、何故か速度的な部分(?)でC++でやることになった

わたしは今更かよと思いながら本をいくつか購入した

以前はCOMも作っていたのだけど、

やり終わったら忘れるし、思い出すのも大変な上に、完全に理解しているとは言えない状態だったのだ

https://amzn.to/41EanOk

https://amzn.to/4axTCZr

https://amzn.to/4aHwkjF

この中で、二冊目のATL Developer's Guideが役に立った

知りたいことは全てここに書かれていた

この一冊だけで良かった

しかし、残念なことに英語

（わたしにはなんの問題もありません）

わたしが解説する必要はないくらいに、

詳しく書かれている

なんとかOO4Oの機能を全て模し、

VB6からはCreateObjectの名前だけを変えれば、

その他に変更点が必要ないと言う物が作れた

これでVB6からはOO4Oは使ってません

ADOです！と言えるわけで、

サポート切れてません！と言い切れるわけだ

と言うか、こんな物を作ってしまったがために、

またもやVB6の寿命を延ばしてしまったのだ

そうだ、わたしだ、、、

戦犯と呼びたいなら呼べば良い、、、

VB6のサポートなんてとっくの昔に切れているのに、

いまだにそれを使っている方が悪い

「善悪という怪物」を読了

 善悪が争いを生むことは間違いない

それに、善悪は非常に厄介だとも思っていた

本書には宗教が悪いとは書かれていなかったが、

それは本書が、善悪で語る事を作者自身が絶対にしないというスタンスで書かれていたからだと考える

善悪で考えることは良い悪いを語り始めると、再帰してしまう

しかし、わたしは宗教の問題は根深いと思っている

古代、無知な人類にも分かりやすくドキュメント化された経典

これなくして人類の道徳感は育たなかった

しかしやがて、宗教が権力を持ち、本来の目的が薄れていった

神の教えに反するのか？

くだらなすぎる

神などいない

アニメが転生ばかりになったのは、一種の宗教だと考えている

天国も地獄も信じられなくなった現代人は、

転生して特別なスキルで無双できたらなぁと考えるようになったのだ

宗教では現代人の直面する問題を解決できない

つまり、宗教はオワコンということだ

金網フェンスの撤去

お隣との間に結構無理やり設置されていた金網フェンスを撤去していただいた

朝八時半から午前中だけで作業は完了していた

とても早くて助かる

狭い隙間には薮からしが太い根っこを張り、壁が侵食されていた

他にもクサギなども生えていた

壁はとても見た目が酷くみっともなかったので、少し前に家のペイントもしてもらっていた

薮からしも引き剥がしてもらっていて、見た目だけはマシになった

当時ついでに壁の撤去をしようと思っていたところ、

ご近所でもペンキ塗りの仕事が多く、話が流れてしまっていた

今回壁を撤去したことで、かなりスッキリし、

残った薮からしの根っこも除去しやすくなった

隙間にゴミを放り込まれていた事もあって、

壁はずっと前から撤去したいと思っていたのだ

まずは除草剤、その後はコンクリで固めてしまおうと計画中

システム手帳

 わたしは紙の手帳を使っている

データ保存場所で大震災のような災害があったとき、

データが全損するHDDと比べたら、紙のほうが再現できる可能性が高い

手書きをすることで手先の刺激になり、脳への刺激にもつながる

ところで、いわゆるB6システム手帳は

リフィルのサイズがB6というわけではなく

手帳のサイズがB6なのだ

手頃に手に入るB4、B5の紙を切って、

穴を開けて手帳のリフィルを作ることがある

そのたびに、B6の紙に書きたいと考えていた

リフィルは縦長のサイズで

メモは取りづらいと感じている

無ければ革を使って自分で作ればいい

下敷きも薄い金属で作るべきだ

しかし面倒なので誰か作ってくれないものだろうか・・・

または既製品があるのであればそれでもいいのだけど

軽く検索しても見つからなかった

continuous vs contigous

https://www.holisticseo.digital/theoretical-seo/content-writing/confused-words/contiguous-continual-vs-continuous

本を読んでいて、Contiguousという単語が出てきて、

え？と思って調べたら出てきました

DB初心者がDBMS作ってみたとかいう記事を見たのだが

作ってなくねぇか？

作られたものを見て感想述べてるだけじゃないか

自分で1行でも書けば

何が大変なのかわかると思うんだけど

ただ人の書いたものを見て

自分で作った気になってるだけ

恐ろしい時代になったものだ

同窓会にて

渋谷のんべい横丁で店をやっている知り合いが居て、そこで十人規模の同窓会がありました

大学時代、友人の家に泊まり込みプログラムをしていました

あの時代があったから今の自分があると思っています

当時、ディスク起動するOSを作り、音源ドライバ、マウスドライバなどを仕込んで、ゲームを作ってコミケで売り、そこそこの売り上げを出しました

久しぶりに会ったその友人は田舎のプログラマをやっていて、VB.net一本槍、Javaは習得できなかったとの事

これを聞いて少しショックでした

わたしは20種類以上の言語を身につけています

今後どんな言語が出てきても一瞬で理解して身につけられるでしょう

実際Swiftを勉強しはじめて、6日でソリティアAppStoreにをリリースしました

店のオーナーは田舎がテキサスでノートン360やオフィス360の仕掛け人です

店長は人に騙されたりなんだりと話をしてくれましたが、その中で共感したのは、相棒はいるか？と言う問いでした

わたしは育ててはいると答えましたが

育てられない、出会うしかないのだと言います

確かにそうです

人は育てても育たない

出来る人は勝手に育ちます

どこかで出会うことは出来るのでしょうか

わたしが仕事を任せられる知り合いに

出会う可能性はゼロでしょう

今まで出会った

自称フルスタックエンジニア達

自称スーパープログラマ達

あなた方は似非でした

わたしは相棒は居ませんが

ゲーム業界時代に知り合った化け物は3人居ます

わたしでさえ一生勝てない化け物どもです

その彼らに比べたら

未踏の連中もゴミにしか見えません

わたしはこの日本には

陽の光の当たらない裏舞台に

名も知られていない化け物が居ることを知っています

プログラマに大事なこと（というか老けない思考のために大事なこと）

「国語」、「英語」、「物理現象の」＋「観察」

この３つは必要です

まず「国語」「英語」について説明します

プログラミング言語は限定された表現方法で束縛された言語です

XQueryではFLWOR

For、Let、Where、OrderBy、Return

他の高級言語では

代入文、条件判定文、ループ

アセンブラのような低級言語で例えれば

Move、Comp、Jump系、Push、Pop（他にもブロック転送やらなにやらありますが）

どの言語でも束縛された表現方法しかありません

一般の方には想像できないでしょうが

この束縛された表現で、画面の項目をチェックしたり

条件によって別の処理を行ったりなどを行っています

これには論理的思考が必要なのですが

それには修飾子にたぶらかされない「国語力」や「英語力」が必要です

出来れば日本語と英語どちらでも同時に考えられるのがベストです

どちらも使えることでWEBでの検索の幅が広がりますし、

とくに日本語は修飾子などに騙されるので英語で言い換えることで一歩引いたものの考え方が出来るようになります

最近の日本語の悪い例だと

「丁寧に説明します」や「忖度したんです」程度で説明したことになりましたよね？

「では、説明してください」

「では、なぜ忖度する状況になったのでしょうか？」

ということが全く議論されないのには参りました

人工知能の方がまだマシな議論ができたことでしょう

多少脱線しましたが

議論をして要件をまとめたり

コーディングをする上でも

語学力が必要となるため「国語」「英語」が重要という事です。

つづいて「物理現象の」＋「観察」について説明します

もっと単純に「探求心」と言ってもよかったのですが

逆にそれだと「何」を探求するのかわからなくなるため、

より具体的に「物理現象の」＋「観察」と表現しました

これなら誰でも何をすればいいのか分かるはずです

例えば

料理を作る際に最善の方法を模索する

スポーツで守備位置を俯瞰する

プログラムで他人と自分のコードを見比べる

自分のコードを常に疑う

「見えないものを見る方法」を考える

日々このように「物理現象の」「観察」をする姿勢が

「想像力」「創造力」「柔軟な思考」「論理的思考」につながるということです

「想像力」「創造力」「柔軟な思考」「論理的思考」を身に着けろ

と言われても、「どうやって？」が無いため、困ったことはありませんでしたか？

「物理現象の」「観察」をすればいいんです

まだ、なぜ「物理現象の」＋「観察」なのか伝わっていないかもしれないので補足します

ただ「花」や「鳥」「地球」を「観察」してくださいと伝えても

大抵の方は、「観察」ではなく、

ただ「見ている」ことしかしません

それではダメです

これも例を出しますが

UFOかプラズマか

プラズマだとしましょう

なぜプラズマが音速を超えて観察されるのでしょうか？

なぜ何もないところにプラズマが発生するのでしょうか

普通の物理学者であれば、

「プラズマです」では済ませません

説明になっていない事にすぐ気が付くからです

「原理はわかりませんがUFOの飛行原理からプラズマが発生する可能性がある」と言われたらどうでしょうか

こちらの方が説明になっていますよね？

しかも、簡単にこれを否定はできません

否定は難しいので別の見方を示します

例えばオーロラのような状態を想像すれば

発光に適した範囲が広範囲なので光の帯が広範囲に降り注ぐように観察されます

もしかしたら

「UFOは、あたかも高速に光が移動したように見えるプラズマに関連した自然現象なのかもしれません（ただしその自然現象がどのように発生するのかは不明です）」

頭が柔らかければ、このような別の「見方」をいくらでも示せます

「見方」についても補足します

人間とは自分が見たものしか信じません

しかし質の悪い事に

たとえ同じ現象を見ていたとしてもUFOのように別の事を主張し始めます

もっと具体例を出すと

ひき逃げを目撃した人々が

今の車は「黄色」か「青」かという議論さえし始めるのです

実際は「白」だったなんてこともあります

この世界の物理現象を何度も観察し目を養う事です

「枯れた技術」と思われたモーターでさえ、まだまだ改良の余地があります

例えば

赤外線をプラスチックに当てて

その反射光からプラスチックの種別を行う機械を発想し創った人が居ます

オープンソースです

プラスチックの種別と言う「見えないものを見る方法」を見つけたわけです

これも日々光や電波などを観察し、考察し、発想が生まれたはずです

ここまで読んで頂いて恐縮ですが

これらの例では、プログラムに直接役に立っていないようにも感じると思いますので

この点も補足します

正解が一つと限らないプログラムには

柔らかな発想が必須です

先に述べた通り

柔らかな発想が元ではなく、日々観察する姿勢が元なのです

自分の書いたコードを何度も書き直してみること

これがプログラム上達に役立ちます

Pythonなどでは、誰が書いても似たコードになります

つまりある意味コーディングのゴールがあります

しかし、高級言語になればなるほど

また、フルスタックフレームワークであればなおのこと

様々な書き方が許される状況になります

これは非常にまずい事です

ゴールが見定められないのです

どんなにDDDを読んでも

出来上がったアプリはフロントでもバックでも妥当性チェックをして

全体でポリシーが無いスパゲティになりがちです

例えば

SpringならBindingResult使えよ・・・

フロントは条件によってエラー表示だけすればいいだろ

フロントでJavaScriptで妥当性チェックを書くなよ・・

などなど思う事は多々あります

例えば

フラグだらけでぐちゃぐちゃなXAMLは沢山あります

一体誰に習ったのでしょうか？

一体どう調べてそういうXAMLを作ったのでしょうか？

Windowsが元はイベントドリブンであることを知らないで

フラグで済まそうとするからそうなるのです

基礎知識をきちんと調べること

自分のコードに疑問を持つ事

頭を柔らかくすること

帳票システムが無くPDFが作れない？

ならばTeXを出力してPDF化したらいい

既存のDBが遅い？

最善となるDBが無いなら作ればいい

わたしが１０年以上前に廃れ誰からも忘れ去られたXMLDBを作ろうとしているのは

そういう理由からです

あれこれと遠回りしていますが

わたしも日々周囲を観察し調べまくって

柔らかな発想を養っているつもりです

（大事なことなので二度言いました）

（追記）

わたしがここに書いたことはSTEAM教育の一種のようです

STEAMがScience、Technology、Engineering、Art、Mathematicsであるのに対して

わたしは語学力も必要だと主張します

てか、Artってなんだよ

無理矢理すぎるだろ

頭湧いてるんか？

お花畑か？

一億総漫画家レベルの画力を持つ日本人にアートとか片腹痛い

外国人の発想は日本人には馴染まないことが多いと思います

（さらに追記）

しかし、最後にその外人の

ウォルトディズニーの言葉を書いておきましょう

「空想をするときにも、現実を見失ってはいけない」

わたしが「物理現象の」＋「観察」と表現したのは、わたしもアニメの原画、動画を描いていた経験があるからかも知れません

16bit Intel系コンパイラを探す中年プラグラマの記事を見たのだが

何故LSI-Cが出てこない？

わたしのEPSON 386 note-ARには

ターボパスカルその他の環境ぎっしりあるぜ？

「Vim」が根強く愛されるエディタである理由

わたしにプログラムを教えてくれたHAL研究所の金井さんは、viかemacsどちらかを覚えてくれと言ってきました

当時わたしはスーパーファミコンの開発で、

SONYのNEWSにスーファミ開発機材を接続した環境で開発していました

最初はviを使っていました

金井さん曰く、viはexエディタのフルスクリーン版だとの事で、どんなにプアなunixでもviが入ってないと言うことはない

exは一ラインのみ表示する、昔のワープロのような表示領域が少ない状態で編集できるエディタで、viはそれを一画面分表示できるようにしたものという事でした

あとunix環境によってはemacsが入ってない事がある

と言う事でしたので、わたしはviを選択して、スーファミのアセンブラを打ち込んでいました

当時はHAL研究所の作ったCコンパイラがあり、コアな部分はlispで作られていて、あらゆるCPU向けのアセンブラを吐き出す事が出来るとの事

わたしは恵まれたことに、Cで打ち込んだコードからどのようなアセンブラが出力されるのかを確かめながら、慣れないスーファミのアセンブラを学ぶことが出来ました

いわゆるトップダウンで、あの難解なスーファミのモード7もアレコレ試す事が出来ました

かなり意外でしたが、当時のゲーム機は全てvsyncやhsyncの割り込みでスプライト描画やスクロール処理などをするプラグラムで動いています

この割り込み中に処理が出来なければ、処理落ちと言う現象になります

最初はviを使っていたのですが、隣の金井さんはemacsでメールを開いたりしながら作業しています

それがめちゃくちゃ羨ましくなり、わたしもemacsに移行しました

しかし、emacsでもviモードでした

viに慣れた人にはホームポジションから手を離さずに打ち込めるviスタイルの方が手への負担が少ないのです

しかしemacsなら画面分割出来るし、terminalも開く事が出来ます

ここでも金井さんに教わりましたが

unixで作業する人は、ターミナルからemacsを立ち上げ、すべての作業をemacsから行い、emacsを終了して作業を終えるとの事でした

なるほど確かにemacsからすべて出来ました

これは、スーファミ現役時代の話です

この話自体がかなり昔の話なのですが

その当時から見ても、

昔の人は本当に恐ろしいと感じました

今の時代はvimになったようですが

かつて、emacsクローンの流行った時代がありました

vimから入るのもありですが

lispで作られたemacsも味わって欲しいと思います

当時lispで動くrogueライクゲームをプレイして、

風来のシレンが出た時は、え？これパクリじゃんて思いました

まぁ、vimというか、viが使われるのは

何もエディタが無い環境でも

viは動くでしょうと言う安心感があるため

とりあえず.bash_profileなどを編集する際などは普通にviです

nanoとかよく分かりません

Windows + WSL2 + VSCでgit pull時に何やらエラー

git pull 時にエラーがでた

問題は２つあった

１．couldn't resolve host

resolve.confに以下追加

sudo vi /etc/resolv.conf

以下２行追加

nameserver 8.8.8.8

nameserver 8.8.8.4

２．TLS関連のエラーがでた

最近TLS1.3になりかけている過渡期なので、多分それが原因だろう

git config --global http.sslVerify false

これで無効にしておいた

C#のプロパティに関する記事

最近、Googleのアプリ開いてるとクソ記事が偉そうに出てきて

今回はC＃のプロパティに関する説明記事だったのだけど

気になったのは、

「ならば全部Publicにすればいいじゃないのと思うかもしれないけど、

C＃ではPublicにするのは非推奨です」で済ませてる点

何故、内部変数をpublicにしないのかと言うと

値のセットやゲットをするときに、

関連する値との整合性チェック機構を入れたり

変数のセットをしたり出来るようにするためです

Getter/Setterもカプセル化して機能を入れるのは悪いことではありません

Javaなんかだと、Lombokで＠Getter,＠Setterしてしまって、

なんの機能も実装しないので、

たしかに、あれだとpublicでいいじゃん？てなります

そして、わざわざLombok使わなくても

Javaでプロパティ構文入れればいいじゃん？てなりますが

現状見送られています

たしかJava7あたりでそういう話題があったはず

さらに言うと、Javaでは

@Lengthや@PatternなどでEntityの整合性をチェックし、Controller内でValidateのチェックをするので、

Entityはまぢ単なる入れ物のため、

Publicでいいじゃん？はい、そうですねってことになります

まぁ言語が違えばこんなもんです

Golangだと、そもそも脱オブジェクト指向言語ですので、

お前らオブジェクトだのクラスだの使ってて、それ再利用してますか？

してないよね？だから俺らモジュールにします！って言語なのです

こういう点からも、

ＤＤＤ書いた人がこれからも偉ぶっていられるとは、

わたしは思っていません

言語によっても考え方が違うのですが、

元記事はＣ＃について書いていて、

単に「C#ではpublicにするのは非推奨です」の一言で片付けるのは如何なものだろうか？

説明にはなってないですよね？

今更帳票システムをゼロから作っている人が居るようだが

それって例えば、

適当なスクリプト言語で、

適当にLaTeX出力させて、

あとはPDFにすれば良いんじゃないの？

Graphvizを組み合わせても良いですね？

わたしならそうします

たかだかC++の開発環境を整えたりFTPサーバのセットアップを紹介するだけの記事をありがたがる人達へ

日本の技術は地に落ちましたね