gitを使わずにディレクトリコピーでバージョン管理2
バージョン管理をただのバックアップと勘違いして
バイナリ形式だと将来データが取り出せなくなるかもと
ありえない話をして学生にデタラメを教え、
独自のバージョン管理(?)を教えて世界に通用できなくする講義
初めてのPOSIX原理主義
https://richlab.org/coterie/lpf.html
> 第12週 POSIX原理主義による二つのデバッグ法とバージョン管理法概論
前スレ gitを使わずにディレクトリコピーでバージョン管理
https://mevius.5ch.net/test/read.cgi/tech/1631002816/ Gitの仕組みを調べればわかることだけど、GitはZIPでファイルを圧縮してハッシュ値でそれを管理してるだけだよ、Gitが優れているのはUnixとの親和性だよ、Gitを使わなくて同じことができるところにGitの美しさがある gitだと何十年後とかアプリが動かないから取り出せないなんてあり得るぞ
まあその頃にそんな化石コード取り出したい奴なんか居ないけどな
化石標本として取り出したいなら、やっぱりフォルダごと保存だろうな >>3
エミュレータ使えばいいやろ(爆笑)
ハードウェアが原因のもの以外でソフトウェアの歴史が始まって依頼
データが取り出せなくなったものなんてないわ >>3
ファイルシステムもソフトウェアなんやで
読み取れなくなるリスクは同じくらいある gitに意味不明な仮定で難癖つけたところでユニケージのゴミプロダクトの質は上がらないぞ そんな偉そうなこというなら最近の論文論破してみ
まあ論文として出てる以上、正しいことが証明されているわけだが
データ駆動型ユニケージアーキテクチャの提案
著者情報
當仲 寛哲 有限会社ユニバーサルシェルプログラミング研究所
S. ブヤンジャルガル 有限会社ユニバーサルシェルプログラミング研究所
鈴木 明夫 一般社団法人持続可能なモノづくり・人づくり支援協会
山本 修一郎 名古屋国際工科専門職大学
https://www.jstage.jst.go.jp/article/jsaisigtwo/2022/KSN-031/2022_04/_article/-char/ja
あらまし 従来のコンポーネントアーキテクチャには,コンポーネント間の依存関係があるため,疎結合アーキ
テクチャの実現が難しいという問題があった.そこで,本稿ではコンポーネント間の依存関係を機能共通性,デー
タ結合性の点から①ライナーによる共通機能の分離,②パイプによる共通機能のデータ結合する疎結合アーキテ
クチャの構成を可能とするユニケージアーキテクチャを提案する.さらに,具体例に提案手法を適用することに
より有効性があることを確認する. ######商品カテゴリー別に売上集計ライナ#######
join1 key=2 PRICE SALES |
join1 key=2 CATEGORY |
lcalc '$3,$7,$8,$8-$7*$4' |
msort -p4 key=1 |
sm2 1 1 2 4 |
sm5 1 1 2 4 |
divsen 2 3 4 |
lcalc '$1,$2,$3,$4,100*$4/$3' |
marume 5.1 |
join2 key=1 CATEGORY_NAME > REPORT.SALES
###商品カテゴリー別に売上集計ライナ終了#### 倉庫管理業務の実装例:
############銘柄在庫管理############
join1 key=1 積荷票 出庫依頼票 |
lcalc ‘内蔵品数量-依頼数量’標準入力 |
awk ‘$差異>=0’ > 中間ファイル
if [ ! -s 中間ファイル ]; then
# 空の場合
不足通知処理実行
終了処理
Fi
# 在庫確認処理・ライナー終了
##############銘柄出庫##############
self 内蔵銘柄コード コンテナ番号\
差異 中間ファイル |
up3 key=内蔵銘柄コード/コンテナ番号 積荷票データ
標準入力 >積荷票.UPDATE.20220822
###########コンテナ管理##############
sm2 1 2 3 3 積荷票.UPDATE.20220822 |
selr 3 0 > 中間ファイル >>9
sm2や1 1 2 4 とか可読性最悪じゃん、なにこれ >>10
元のコードを見ろ
可読性なら日本語のコメントで解決できる マジックナンバーだらけのコードを書かなければいい
省略した関数名つけなければいい
コメント見なくてもコード見ればわかるのが可読性の高いコード >>12
ユニケージの教えを読め
https://uec.usp-lab.com/JOURNAL/CGI/JOURNAL.CGI?POMPA=SAHOU_journal10
「マジックナンバー」の意味を書け
リスト1の36行目「完了フラグ2」とあるが、2という数字(マジックナンバー)が
何を意味するのかさっぱり分からない。リスト2の44-45行目のようにして、数字の意味を書くべきである。 lcalc '$3,$7,$8,$8-$7*$4' |
さ・い・あ・く 書いた人間でさえコメント消したらこのコード見ても何やってるかわからんだろ >>17
コードはコンピュータのための言語
人間はコメントを読む >>18
クソワロタ、コードの可読性が最悪だからそうせざるを得ないってだけだろ >>19
参考になるやろ?
https://uec.usp-lab.com/JOURNAL/CGI/JOURNAL.CGI?POMPA=SAHOU_journal10
松浦智之著、「第八回 ユニケージエンジニアの作法」より加筆修正後転載
松浦智之でググれ
コンピュータ言語は人間のための言語
その作法を伝える前に一度考えてみてもらいたいことがある。
コメントを記すための仕様は、プログラミング言語はもちろん、HTMLなどのマークアップ言語や、
問い合わせ言語の一種である正規表現まで、ほとんどすべてのコンピュータ言語で規定されている。
☆コメントを記すための仕様 ☆コメントを記すための仕様 ☆コメントを記すための仕様
まるで、その規定がなければコンピュータ言語として失格であるかの如くの徹底ぶりである。果たしてこれは一体何故なのだろうか。
筆者はこう考える。コンピュータ言語とは、コンピュータのためよりも、むしろ人間のための言語であるからだ、と。
もし、人間のためよりもコンピュータのためが優先されるのであれば、
コンピュータにとってはまったく無意味で無駄で、しかも無視するのにも手間が掛かるコメント機能など、
積極的に廃止すべきである。実際、コンピュータのためといえるほぼ唯一の言語である
機械語(アセンブリ言語ではない)は、その通りになっている。すなわちコメントという命令が存在しない。
☆コメントという命令 ☆コメントという命令 ☆コメントという命令
この機械語という例外を除き、コンピュータ言語とは実に奇妙な言語だ。なぜならば、
コンピュータ言語を話せる(作文できる)のはコンピュータではなく人間だけであるからだ。
コンピュータは、それを聞いて態度を示すのみ。話し返すことができないのだ。
そんなコンピュータ相手に会話を成立させるには、コンピュータが示した態度を汲み取りながら、
過去に自分や他人が話したコンピュータ言語を自分で読んで、新しい内容を再び話してやらねばならない。
話しもするし、聞きもする。よって、コンピュータ言語により深く関わっているのは、人間の方なのである。 結局何が言いたいんだよグダグダとなんの言い訳してんだよ 上手にコメントを書く練習するんじゃなくてマジックナンバーだらけのクソコードを捨てろよ lcalc '$1,$2,$3,$4,100*$4/$3' |
なんだこのクソコードは$1はなんだ
どこ見ればわかるんだ?ああ? スクリプト組むとかあっちの方向に話が飛んでるが
本筋に戻す気無いの? 本筋に関して言えば、ユニケージはゴミ、バージョン管理はGitが優秀
で終わりだからなぁ ジュンク堂にユニケージ原論があったから少し見たけれど宗教じゃないか
宗教の棚に置くべき >>24
パイプラインなんて今どきライブラリレベルでサポートされてるんだわ ユニケージってDBも使わなくて独自にファイルで管理するんだろ、業務アプリなら1億レコード扱うのもザラにあるがユニケージはインデックスの管理もファイルでやるのか?grepでも時間かかるだろ クソコードを書いて気持ちよくなってる人もいる
業務で本格導入した東急ハンズに技術的負債と評価されたユニケージは理論に瑕疵があるとしか思えん
シェルスクリプトにこだわるのが自己満足にしかなってないということだと思う だってあそこの社長「パイプを何十本も繋いでメーカーの人に嘲笑われた」
悔しさから、意地でパイプ使ってやろうとしてるだけだしな
パイプを何十本も繋いでメーカーの人に嘲笑われた
https://uec.usp-lab.com/TUKUBAI/CGI/TUKUBAI.CGI?POMPA=TOUNAKA_INTERVIEW_02
> そこでUNIX的思想に則り、パイプを何十本と繋いでいってデータを流して処理を実現させてみました。
> 「やったー。ほら出来た!」と喜んでいても、当時、シェルでパイプを繋ぐなんてありえなかったので、
> それを見たメーカーの人が嘲笑いましたね。「コンピューターの使い方を間違えてる」って。
結論?「コンピューターの使い方を間違えてる」
それが答えだよ。パイプを何十本と繋いでいるせいで
プロセス高荷になり、forkできなくってそれで東急ハンズはシステム停止に陥った クソコード書いてるのが馬鹿にされるのが悔しくて、
これがUNIX的思想だとか、言ってるだけ
実際にはUNIXの考え方をな~んも理解しとらん
USP研究所はそんな連中の集まり >>29
100万レコードを10秒で処理できるとか、
そんな遅い自慢をしてたよ サイトの速さが実力を表しているのでは?
滅茶苦茶速い。
これもゆにけーじ? サイトの速さ?お前ベンチマークしたの?
誰もアクセスしないし、あれくらい普通でしょ。
ユニケージは大規模アクセスに耐えられないから
無印とかでシステム停止に陥った。 だからアクセスが集中した時は遅いってw
それにあれぐらいの速度であれば
WordPressとかでも出せる >>41
僕の感想であり真実ですね
僕には真実を見抜く目があります
僕の目にはユニケージはゴミと映ります >>42
もし本当にユニケージがゴミなら
こんなに関連書籍が出版されているはずがないだろ
人気なんだよ 過去のバージョン管理ツールで肥大化したプログラムに泣かされた人は少なくないだろう サイトがメチャ速い。
これもユニケージで出来てるの? >>43
>>7のPDF
https://www.jstage.jst.go.jp/article/jsaisigtwo/2022/KSN-031/2022_04/_article/-char/ja
PDFの処理をSQLで書いてみた
https://www.klgrth.io/paste/6337x
このSQLを見てごらんよすごくわかりやすいだろう
PDFで提案されてるコードはこれだよ
> sm2 1 2 3 3 積荷票.UPDATE.20220822 |
> # 集計が 0 のコンテナを抽出
> selr 3 0 > 中間ファイル
・sm2 1 2 3 3
・selr 3 0
・中間ファイル
提案のコードは独自コマンド,独自ファイルだらけで引数も何を渡してるのかパッと見わからないよね
業務アプリでは致命的なほど可読性が低くて保守しづらい
一方、SQLはISOで規格が決められていて誰もが知っている共通のコマンドで処理を書けて業務アプリに最適
素直にDB使った方が良いと思うんだよね ユニケージが人気という風聞は聞いたことがないし
ユニケージの関連書籍が多いとも思わないな
書いてるのは全部USP研究所だもん、自作自演だよ DBを使えば処理がわかりやすくてクラウドへの移行もやりやすい
BigTableやRedshiftを使えば億単位の処理もサクサクできる
ユニケージのデメリットは
・可読性が低い
・保守性が低い
・クラウドのサービスを活用しづらい
あたりかな
ユニケージを推進しようとするのは心理学的にはNot Invented Here、NIH症候群(自前主義)のように思われる >>48
自作自演でも、シェルスクリプトマガジンとかも出してるし
ちゃんとした出版会社でしょ?そこは凄いと思うよ。 色んな人がユニケージ関連の書籍を出版するならユニケージが人気ですごいと思うけど
自作自演の出版を人気だとは思わないしすごいとも思わないな ユニケージは技術的にもそんなに良いものじゃないのは上に書いた通り >>51
本を出版するのは凄いことだと思いますが?
どこかの大手にお金を払って出版してもらっているわけではなく
会社自体が出版会社を兼ねているわけでしょう?
出版会社としては小さいかもしれませんが、例えば
アスキーとかインプレスみたいなものなわけで
どんな会社でもできることではありませんよね。 ユニケージはノンコードと同じ理念と考えて良いですか? >>56
いいえ、ノンコードではなくローコードです。ユニケージではusp Tukubaiと呼ばれるコマンド群を使います。
無駄なソフトウェアレイアーを除いた OS に限りなく近い実装により、圧倒的な性能と安定性を提供します。
ユニケージ開発手法 製品ラインナップ https://www.usp-lab.com/product.html
ユニケージ開発手法で中心となるコマンドセット。OS標準のコマンドと組み合わせて使用します。
OS標準のコマンドでは不足している機能・性能を補ったり、プログラムを短く書くための工夫がなされています。高速処理も特長です。
usp Tukubai リーフレット https://www.usp-lab.com/DOWNLOAD/PDF/PRODUCT_uspTukubai.pdf
join1 key=2 PRICE SALES | # 2つのファイルのKeyで連結
join1 key=2 CATEGORY | # カテゴリを連結
lcalc ‘$3,$7,$8,$8-$7*$4’ | # 整数18桁、少数18桁の高精度演算
msort key=1 | # オンメモリーソート
sm2 1 1 2 4 | # 小計
sm5 1 1 2 4 | # 総合計
divsen 2 3 4 | # 1000で割る
divsen 3 4 | # 1000で割る
lcalc ‘$1,$2,$3,$4,100*$4/$3’ | # 粗利率を求める
marume 5.1 | # 小数点以下丸め
join2 key=1 CATEGORY_NAME | # カテゴリ名称をつける
comma 3 4 5 | # 数字にコンマをつける
keta | # 桁揃えをする
keisen +e | # 罫線を引く
cat header - k # 出力する
やすい コストが安い・プログラムが易しい 開発コスト4分の1
はやい 開発期間が短い・処理が速い 開発期間4分の1、処理速度10分の1
やわらかい どんな性質のデータも取り扱える 変化、異種、重複、不確定、履歴、etc
ながつづき データもプログラムもコピーだけで移植可 システム寿命25年以上
高速なデータ処理を行います。1000万件の集計が0.67秒、ソートが2.29秒!
こんなすごい開発手法、見たことないでしょう? >>57
SELECT
CATEGORY.部門ID
, MAX(CATEGORY_NAME.カテゴリ名)
, SUM(SALES.売数)
, SUM(PRICE.仕入値)
, SUM(PRICE.売値)
, SUM(PRICE.売値) / SUM(PRICE.仕入値) * 100
FROM
SALES
INNER JOIN
PRICE
ON
SALES.商品ID = PRICE.商品ID
INNER JOIN
CATEGORY
ON
SALES.商品ID = CATEGORY.商品ID
INNER JOIN
CATEGORY_NAME
ON
CATEGORY.部門ID = CATEGORY_NAME.部門ID
GROUP BY
CATEGORY.部門ID
ORDER BY
CATEGORY.部門ID >>61
千で割るからdivsenだよ。わかりやすいやろ
このセンスが海外でもオオウケ
https://unicage.eu/ チュクバイは名前がダメだな
コマンド名の品質が低い
パイプラインの本質は宣言的プログラミングで目的がわかりやすくなることだ、しかしチュクバイはわかりにくい、抽象化に失敗してるとしか思えぬ
ユニケージは負の遺産 SQLは宣言的プログラミング言語、ユニケージのパイプラインは所詮SQLの劣化版でしかない >>66
TukubaiはUNIXのコマンドの拡張。だから処理速度も高速。
UNIXコマンドは優れている。優れたコマンドは短い名前を持つ
名前が短いということはTukubaiを使うとコードが短くなる
コメントを除けばSQLなんかよりも圧倒的に短い
だから開発コストも4分の1になるというわけ ユニケージがOSに近いところで動くとか本気で言ってるんだろうか