2024年7月31日水曜日

構文木

https://trilltrill.jp/articles/3740097

答えは3なんだけど、
LRで構文木を作ると

まず、Rを探しに行く
右端は+ 1
                    PLUS
                /                \
       5/(8-3)*2           1

続いて、LからまたRを探すと、* 2

                    PLUS
                /                \
            MUL             1
          /          \
5/(8-3)      2
さらにLの5/(8-3)にRを探すと/ (8-3)

                   PLUS
                /               \
            MUL           1
          /           \
       DIV          2
     /       \
   5      8-3

んで、今度はR側にまだ再帰できるところがあるので

                   PLUS
                /               \
            MUL           1
          /           \
       DIV          2
     /       \
   5      MINUS
           /             \
         8              3
これで構文木が完成

そんで、答えを出すには最下層から上に上がっていく
8-3=5なので
                   PLUS
                /               \
            MUL           1
          /           \
       DIV          2
     /       \
   5         5

続いて
 5/5=1なので
                   PLUS
                /               \
            MUL           1
          /           \
        1          2
 
さらに続けて
1*2=2となり
                  PLUS
                /               \
              2                1

最後は
2+1=3
という事で、答えの3が導ける

ここで、数式とプログラミング言語を比べると、C言語なんて関数なので、

例えばif文
if (a==b) {
    proc();
}

          if
       /       \
    ==    proc()
   /      \
a        b

のようになるし、forも代入も似たようなもんで、構文木を作って解釈して行くことになる

このやり方はクヌース大先生が考案したもので、その後多くのアイデアが出てくるのだけど、基本はやはり構文木を作るというやり方になっている

そして、lexやyaccが生まれ、
構文木を自動生成するためにBNF記法が生まれ、C言語などのプログラミング言語が出来た

C++では構文定義をC++の記法で置き換えたboost::spiritsなども生まれ、すぐにこの変態的実装はなくなるかと思ったが、C++17でも残ってる

lexやyaccは
flexやbisonになったが
わたしが最近触っているANTLRは構文定義からGoやSwiftのコードも出力できる

好みの言語で新しい言語を作ることができるようになってきた

2024年7月20日土曜日

XML2Json再考

突然思い出したので
忘れないうちに書いておきます

Xerces Xalan
今はなかなか見かけない
この2つのプロジェクトは
XMLを扱っていた人ならご存知でしょう

実装の中身を見ていませんが
XMLをDOMとして扱っておらず
逐次的に処理をする実装になっていると聞いたことがあります

DOMについて
公式での解説も何だかパッとしないので改めて説明します

DOMと言うのは、XMLのツリー構造を構造体などを利用してメモリやファイルなどに保存しておいて、高速にアクセスすると言う仕組みです

例えばHTMLはブラウザでツリー構造が扱えるようになっていて、そのためにDocument.getElenentByIdのようなアクセスが可能となっています

これに対してDOMでは無いパースとは、XMLを単なるテキストとして扱い
上から順にパースして該当項目を探すので
あまりパフォーマンスは良くありません

このようにXerces Xalanは逐次的にパースするので
XMLを一度DOMとしてメモリやファイルなどに展開する時間はゼロです

巨大なXMLを扱う場合にはそれをDOMとしてメモリやファイルに保存しないため、メモリやファイルの消費を抑えることが出来ると言う利点もあります

なぜ突然この二つを思い出したのかと言うと、、、

わたしが以前Goで作ったXML2Jsonの実装を見ていて
DOMでは無い方が良いかも知れないと思い始めていたからです

当時の実装は逐次的にXMLのパースを行うGoのライブラリを使用して、XMLのTokenを取得しながら自前のDOMを作り、そのDOMからJSONに変換すると言う実装でした

しかもその変換関数は再帰ルーチンとなっていました

どうも無駄だらけに見えてきました

やはり一度作ったプログラムは何度か作り直さないとダメです

わたしは天才ではありません

2024年7月12日金曜日

地熱

G Mm/r^2
このエネルギーは潮の満ち引きなどを引き起こしている
そのエネルギーは地表の水だけでなく
地球中心と月中心間の距離の二乗に反比例し
互いの中心に絶えずエネルギーが発生していると考える
同じ事が地球と太陽でも起こり
金星と太陽でも起こっていると考える

金星の表面には太陽の熱エネルギーと金星の内部に溜まり続ける熱エネルギーによって絶えず嵐が吹き荒れている

太陽の吹き出す熱エネルギーも重力も断然金星の方が強い

2024年7月11日木曜日

ススホコリ





しばらく前に庭に発生したススホコリ

GoによるJSONのパースについて

Go言語には、JSONのパースをする際に構造体が必要になるライブラリしかなかった

社員から、その点について質問があり
構造体のように枠が決まっていないと
セキュリティ上の問題になりやすいと言うことを説明した

パースする相手がXMLでも同じ状況だった

そこでわたしは以前、任意のXMLをパースして、汎用的な構造体を使ったメモリーマップに保存することにした
そして、そのマップからJSONを作り出すこともやった

その構造体メモリーマップにパースする事は、XMLでも出来たので、JSONにも対応可能だ

というか、JSONのが簡単だろう

それで最近の状況はどうなのか調べてみると、メルカリの技術者がJSONのパースについてライブラリを作っていたのを見つけた

gitの中身は見てないが、やり方は同じなんだろうと思ってる

わたしは以前自分が作ったものに少し不満があった

その不満を突き詰めるとXML Databaseになってしまうのもわかった

MongoDBのSQLite版的な位置付けの物で、内部データはXMLと言うものになり、XQueryを処理する形でデータを抜き出すと言う簡易データベースだ

こいつがかなり厄介で
XQueryの実装に難儀している
モチベも続かない

しかし、今回社員からマイクロサービスの用途でJSONのパースの話を聞かされて、以前作った物がそのまま使えそうなことに気がついた

冒頭で書いたJSONのパースについては、JavaScriptでフロントからのリクエストがあった時に、通信内容はJSONにした方がいいと意見した流れだったのだけど、XML HttpRequestならそのまま使える
JSONをパースする部分を作れば、相互変換もできる
さらに、ファイルシリアライズを実装すれば、あとはXQueryの実装にも使えるようになる

頭の中であれこれスッキリ繋がった気持ちになっている

やはり一人で考えているより、人と話している方が捗る

2024年7月10日水曜日

日経はマヂクソ

「プログラマの選民意識」とか言う記事を見かけた

日経というところは
誇大広告、ガセネタ、炎上記事だらけ

新電池とか新燃料電池とかどこで実現された?
株というものがそういうゆさぶりで動くのは知ってるが
もう正直馬鹿らしくて付き合ってられない
わたしには経済という物が向いていない

記事の内容はマヂで酷い
騙されてはいけない

頭が悪くなる
時間の無駄

わたしは競プロが嫌いだ
あーいうのにのめり込む暇がない
脳の瞬発力には自信がないというのも理由の一つだが
考えるなら別のことを考える

全プログラマを一緒くたに語るのはやめるべきだろう
少なくとも私には選民意識はない
わたしができる程度のことは誰でもできると思っている

プログラマなんてものは
「プログラムなんて誰にでもできる」と考える人種にとっては最下層の存在です
あたりまえのことがあたりまえにできるだけの存在ですよ?

だからわたしは、
プログラマなんてのは最下層の底辺で地べたを這いずり回る虫野郎だと思ってます

大手様で「プログラムなんて誰が書いても同じ」と発言したPMが居ましたが
ならばお前やってみろと思ったと同時に、
本当にそういう人居たんだなぁと思いました
多分一生忘れないでしょう

そんな簡単なもんじゃないですよ
だから最底辺の人間たちが奴隷労働させられてるんでしょう?

わたしはそういう勘違い系のPMの方がよっぽど社会悪だと思っています

なので、プログラムさえできない人はPMとかやらないで欲しいし
元プログラマというプログラマとして一生過ごすのをあきらめた皆さんには
素直に業界から去ってほしいとさえ思います

だって、最低のことさえできないんですよ?

2024年7月9日火曜日

Unityのデータ指向には賛成(と言うかゲームはそういう作りにするべき)

 https://game-ace.com/blog/unity-dots-system/

わたしが作っているゲームエンジンはデータ指向でありオブジェクト指向なのだけど、Unityはオブジェクト指向が嫌いなようだ

両者は対立するものではない

オブジェクトがデータに沿って動けば良いだけの話だ

わたしはGo言語もやっているので、モジュール指向で作ることには抵抗が無いし、オブジェクト指向に凝り固まったJavaは嫌いで仕方ない

Goの作者がC++はなんか違うと思い続けてGoが作られたのも納得している

確かにクソコードの作者はクソなクラスを山のように作り出す

それ、なんのため?

意味わからん

遅いだけじゃん!

ずーーーーっとそう思い続けていた

繰り返しになるがオブジェクト指向がクソになるのはクソコーダーの所為なのだ

クソコーダーはアセンブラからやり直せ!

Windowsのクラスがクソなのは間違いない

あのクソ構造なMSお作法のために何人の有能なプログラマがその道を諦めたことか、、、

わたしは全部見て来たが、見ていない人には何もわからないだろう

こうやって歴史は大きな勢力に上塗りされるのだ

ところで、この紹介ページの図

下手すぎ

なんだこのJobが沢山ありますよ的な図は、、、

わたしがUnityを嫌いなのはC#だからだ

C#はJavaが欲しかったMSが苦し紛れに作った言語で、生まれながらにポリシーが無い

C#はクソ真似言語だ

登場当時、C#はC++--(シープラプラマイナスマイナス)と言われていた

C++からオブジェクト指向以外のものを削除した言語という意味だ


こんな古い話、今では知っている人も居ないだろう


とにかく面白く無い言語で、ゲームに向いているとは思えない


あんなもんやるならSwiftやGoの方が何倍も素晴らしい

2024年7月5日金曜日

Doxygen

今更かよ


Call Caller図も出す設定してるなら
こんな図が出ますよって出した方がよくないか?

あれあると、影響範囲見るの楽だよ?

ゲームエンジンでパーティクルの実装

パーティクルを実装しました

正直目が痛い・・・

でも、まぁ思ったように実装できたと思います

まだ、いまいちなところもあるので改善点を考慮中です




ランサム

あちこちでランサムが流行ってる

業務系のアプリがクローズド環境だから安心→んなわけねぇ

データベースが暗号化されてるから安心
→IDとパスワードなんて簡単に突破される

PFX認証ファイルをWindowsにインストールしている→Windowsの時点で全然安全ではない

AzureだしVPNだし!→IDとパスワードでしょ?

WEBアプリだけどトークン認証してるし!→トークンはブラウザで確認できるしそれを一瞥しただけで記憶できる人間もいる、なんならスマホで撮影しとけばいい

セキュリティに終わりなんかない
日々アンテナを張って勉強し続けないといけないし
漏洩したくないならデータを持つべきではない

個人や企業のデータを売買する会社は多い
しかし、そのデータは売り物にされて出回っているし、間違ったデータも多い

こういうデータに価値はあるのだろうか?

Googleは個人個人が検索したワードを全部記録しているし活用もされてる

わたしは、、、
個人データがそこまで重要なのかという点に実は疑問を持っている

個人情報は保護されるべきなのか?

わたしはオープンでありたいし、わたしの個人データが知れ渡ったところでだから何?とも思っている

とはいえ、わたし名義でローン組まれたり、誰かの口座に振り込みされたら困る

仮想通貨、電子マネーなどは、今よりもっと攻撃が集中していくだろうと予想する

2024年7月4日木曜日

サードパーティ製品が嫌い・・・

 わたしはサードパーティ製品が嫌いだ

あんなもの自分で作れるわと思うものばかりだ

その中で最たるものが大昔から存在している文化オリエントだかなんだかから引き継がれているあの製品群だ

自分でつくれよ・・・

そもそもWindowsはそれができる

それを行うための資料もある

だから彼らもそういったソフトを作れるのだろう?

まったくもって、あれらを使う必要性がわからない


ところでPDF出力もそうだ

TeXでも使え!

帳票でもなんでも作れんだろ!


んで、わたしがこれらを嫌うのは

オープンではないからだ

下手するとサブスクだったりする

もうやめてほしいわ

そもそも、それらを提供する会社がなくなってしまった場合

サードパーティ製品を使い続けるのか?

我々は何度同じ過ちを繰り返してきた?


オープンであれば、誰かが引き継ぐだろう

わたしはこの点からも

プログラムはオープンであるべきだというGNUの考え方に同意する。

それ以外のものは使うべきではない

もちろん、Windowsも本来嫌だ


ライ麦

ライ麦

中途半端な実り方をしていた穂からライ麦の種を取り出してみた
これでも結構な量ある
撒いた量よりは確実に多い




2024年7月2日火曜日

庭の手入れ

庭の一角を畑のようにしていたのだけど
管理できない
雨が降った後ぐちゃぐちゃになる

実は最近フェルトの鉢を多用している

この鉢はとても水捌けがよく
保肥力が強い土を用意すればかなり手間を無くせる

そのフェルト鉢の方を見ると
かなり良い土の状態を維持できていて
庭全体これで良いんじゃないのかとさえ思える

雑草も生えないように
防草シートを敷いて
上に砂利でも敷いてしまう方が管理が楽だと考えた

プールシートでも良いかも
フェルト鉢から出ていく水をプールシートに溜め
そこに生物も住まわせて
水の再利用をする

構想はまとまった
あとはやるだけだ