gitを使わずにディレクトリコピーでバージョン管理2

**デフォルトの名無しさん** · 2022/10/14(金) 05:26:57.28

バージョン管理をただのバックアップと勘違いして
バイナリ形式だと将来データが取り出せなくなるかもと
ありえない話をして学生にデタラメを教え、
独自のバージョン管理（？）を教えて世界に通用できなくする講義

初めてのPOSIX原理主義
https://richlab.org/coterie/lpf.html
> 第12週 POSIX原理主義による二つのデバッグ法とバージョン管理法概論

前スレ　gitを使わずにディレクトリコピーでバージョン管理
https://mevius.5ch.net/test/read.cgi/tech/1631002816/

**デフォルトの名無しさん** · 2022/10/14(金) 11:11:43.08

Gitの仕組みを調べればわかることだけど、GitはZIPでファイルを圧縮してハッシュ値でそれを管理してるだけだよ、Gitが優れているのはUnixとの親和性だよ、Gitを使わなくて同じことができるところにGitの美しさがある

**デフォルトの名無しさん** · 2022/10/15(土) 08:47:22.88

gitだと何十年後とかアプリが動かないから取り出せないなんてあり得るぞ
まあその頃にそんな化石コード取り出したい奴なんか居ないけどな
化石標本として取り出したいなら、やっぱりフォルダごと保存だろうな

**デフォルトの名無しさん** · 2022/10/15(土) 08:55:02.78

>>3
エミュレータ使えばいいやろ（爆笑）

ハードウェアが原因のもの以外でソフトウェアの歴史が始まって依頼
データが取り出せなくなったものなんてないわ

**デフォルトの名無しさん** · 2022/10/15(土) 09:38:30.69

>>3
ファイルシステムもソフトウェアなんやで
読み取れなくなるリスクは同じくらいある

**デフォルトの名無しさん** · 2022/10/15(土) 10:00:41.82

gitに意味不明な仮定で難癖つけたところでユニケージのゴミプロダクトの質は上がらないぞ

**デフォルトの名無しさん** · 2022/10/15(土) 10:34:21.03

そんな偉そうなこというなら最近の論文論破してみ
まあ論文として出てる以上、正しいことが証明されているわけだが

データ駆動型ユニケージアーキテクチャの提案

著者情報
當仲寛哲　有限会社ユニバーサルシェルプログラミング研究所
S. ブヤンジャルガル　有限会社ユニバーサルシェルプログラミング研究所
鈴木明夫　一般社団法人持続可能なモノづくり・人づくり支援協会
山本修一郎　名古屋国際工科専門職大学

https://www.jstage.jst.go.jp/article/jsaisigtwo/2022/KSN-031/2022_04/_article/-char/ja

あらまし従来のコンポーネントアーキテクチャには，コンポーネント間の依存関係があるため，疎結合アーキ
テクチャの実現が難しいという問題があった．そこで，本稿ではコンポーネント間の依存関係を機能共通性，デー
タ結合性の点から①ライナーによる共通機能の分離，②パイプによる共通機能のデータ結合する疎結合アーキテ
クチャの構成を可能とするユニケージアーキテクチャを提案する．さらに，具体例に提案手法を適用することに
より有効性があることを確認する．

**デフォルトの名無しさん** · 2022/10/15(土) 10:35:13.49

**デフォルトの名無しさん** · 2022/10/15(土) 10:36:39.35

倉庫管理業務の実装例：
############銘柄在庫管理############
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 ＞中間ファイル

**デフォルトの名無しさん** · 2022/10/15(土) 10:46:52.14

>>9
sm2や1 1 2 4 とか可読性最悪じゃん、なにこれ

**デフォルトの名無しさん** · 2022/10/15(土) 11:15:28.97

>>10
元のコードを見ろ
可読性なら日本語のコメントで解決できる

**デフォルトの名無しさん** · 2022/10/15(土) 11:46:08.22

マジックナンバーだらけのコードを書かなければいい
省略した関数名つけなければいい
コメント見なくてもコード見ればわかるのが可読性の高いコード

**デフォルトの名無しさん** · 2022/10/15(土) 11:48:13.36

>>12
ユニケージの教えを読め

https://uec.usp-lab.com/JOURNAL/CGI/JOURNAL.CGI?POMPA=SAHOU_journal10

「マジックナンバー」の意味を書け
リスト1の36行目「完了フラグ2」とあるが、2という数字(マジックナンバー)が
何を意味するのかさっぱり分からない。リスト2の44-45行目のようにして、数字の意味を書くべきである。

**デフォルトの名無しさん** · 2022/10/15(土) 11:48:16.09

lcalc '$3,$7,$8,$8-$7*$4' |
さ・い・あ・く

**デフォルトの名無しさん** · 2022/10/15(土) 11:51:51.17

こんな保守性皆無なクソコード残される身にもなれ

**デフォルトの名無しさん** · 2022/10/15(土) 11:54:39.52

東急ハンズもそりゃ見限るわな

**デフォルトの名無しさん** · 2022/10/15(土) 11:56:25.85

書いた人間でさえコメント消したらこのコード見ても何やってるかわからんだろ

**デフォルトの名無しさん** · 2022/10/15(土) 11:57:39.86

>>17
コードはコンピュータのための言語
人間はコメントを読む

**デフォルトの名無しさん** · 2022/10/15(土) 11:59:17.35

>>18
クソワロタ、コードの可読性が最悪だからそうせざるを得ないってだけだろ

**デフォルトの名無しさん** · 2022/10/15(土) 12:02:59.18

>>19
参考になるやろ？

https://uec.usp-lab.com/JOURNAL/CGI/JOURNAL.CGI?POMPA=SAHOU_journal10
松浦智之著、「第八回ユニケージエンジニアの作法」より加筆修正後転載
松浦智之でググれ

コンピュータ言語は人間のための言語
その作法を伝える前に一度考えてみてもらいたいことがある。

コメントを記すための仕様は、プログラミング言語はもちろん、HTMLなどのマークアップ言語や、
問い合わせ言語の一種である正規表現まで、ほとんどすべてのコンピュータ言語で規定されている。

　　☆コメントを記すための仕様　☆コメントを記すための仕様　☆コメントを記すための仕様

まるで、その規定がなければコンピュータ言語として失格であるかの如くの徹底ぶりである。果たしてこれは一体何故なのだろうか。

筆者はこう考える。コンピュータ言語とは、コンピュータのためよりも、むしろ人間のための言語であるからだ、と。
もし、人間のためよりもコンピュータのためが優先されるのであれば、
コンピュータにとってはまったく無意味で無駄で、しかも無視するのにも手間が掛かるコメント機能など、
積極的に廃止すべきである。実際、コンピュータのためといえるほぼ唯一の言語である
機械語(アセンブリ言語ではない)は、その通りになっている。すなわちコメントという命令が存在しない。

　　☆コメントという命令　☆コメントという命令　☆コメントという命令

この機械語という例外を除き、コンピュータ言語とは実に奇妙な言語だ。なぜならば、
コンピュータ言語を話せる(作文できる)のはコンピュータではなく人間だけであるからだ。
コンピュータは、それを聞いて態度を示すのみ。話し返すことができないのだ。
そんなコンピュータ相手に会話を成立させるには、コンピュータが示した態度を汲み取りながら、
過去に自分や他人が話したコンピュータ言語を自分で読んで、新しい内容を再び話してやらねばならない。

話しもするし、聞きもする。よって、コンピュータ言語により深く関わっているのは、人間の方なのである。

**デフォルトの名無しさん** · 2022/10/15(土) 12:05:53.45

結局何が言いたいんだよグダグダとなんの言い訳してんだよ

**デフォルトの名無しさん** · 2022/10/15(土) 12:09:26.87

上手にコメントを書く練習するんじゃなくてマジックナンバーだらけのクソコードを捨てろよ

**デフォルトの名無しさん** · 2022/10/15(土) 12:12:54.17

lcalc '$1,$2,$3,$4,100*$4/$3' |
なんだこのクソコードは$1はなんだ
どこ見ればわかるんだ？ああ？

**デフォルトの名無しさん** · 2022/10/15(土) 14:18:59.03

スクリプト組むとかあっちの方向に話が飛んでるが
本筋に戻す気無いの？

**デフォルトの名無しさん** · 2022/10/15(土) 16:02:47.30

本筋に関して言えば、ユニケージはゴミ、バージョン管理はGitが優秀

で終わりだからなぁ

**デフォルトの名無しさん** · 2022/10/15(土) 17:58:40.03

ジュンク堂にユニケージ原論があったから少し見たけれど宗教じゃないか
宗教の棚に置くべき

**デフォルトの名無しさん** · 2022/10/15(土) 18:33:44.96

https://twitter.com/aabbdd129/status/1581212867504005120
シェルスクリプト本、著者名でゴミだとわかるから助かる
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/10/15(土) 20:45:24.58

>>24
パイプラインなんて今どきライブラリレベルでサポートされてるんだわ

**デフォルトの名無しさん** · 2022/10/15(土) 20:49:59.12

ユニケージってDBも使わなくて独自にファイルで管理するんだろ、業務アプリなら1億レコード扱うのもザラにあるがユニケージはインデックスの管理もファイルでやるのか？grepでも時間かかるだろ

**デフォルトの名無しさん** · 2022/10/15(土) 23:07:20.03

>>23
5chでいきって気持ちよくなったか？

**デフォルトの名無しさん** · 2022/10/16(日) 02:18:01.29

クソコードを書いて気持ちよくなってる人もいる
業務で本格導入した東急ハンズに技術的負債と評価されたユニケージは理論に瑕疵があるとしか思えん
シェルスクリプトにこだわるのが自己満足にしかなってないということだと思う

**デフォルトの名無しさん** · 2022/10/16(日) 02:24:03.86

だってあそこの社長「パイプを何十本も繋いでメーカーの人に嘲笑われた」
悔しさから、意地でパイプ使ってやろうとしてるだけだしな

パイプを何十本も繋いでメーカーの人に嘲笑われた
https://uec.usp-lab.com/TUKUBAI/CGI/TUKUBAI.CGI?POMPA=TOUNAKA_INTERVIEW_02

> そこでUNIX的思想に則り、パイプを何十本と繋いでいってデータを流して処理を実現させてみました。
> 「やったー。ほら出来た！」と喜んでいても、当時、シェルでパイプを繋ぐなんてありえなかったので、
> それを見たメーカーの人が嘲笑いましたね。「コンピューターの使い方を間違えてる」って。

結論？「コンピューターの使い方を間違えてる」
それが答えだよ。パイプを何十本と繋いでいるせいで
プロセス高荷になり、forkできなくってそれで東急ハンズはシステム停止に陥った

**デフォルトの名無しさん** · 2022/10/16(日) 02:25:09.99

クソコード書いてるのが馬鹿にされるのが悔しくて、
これがUNIX的思想だとか、言ってるだけ
実際にはUNIXの考え方をな～んも理解しとらん
USP研究所はそんな連中の集まり

**デフォルトの名無しさん** · 2022/10/16(日) 02:38:23.22

>>29
100万レコードを10秒で処理できるとか、
そんな遅い自慢をしてたよ

**デフォルトの名無しさん** · 2022/10/16(日) 02:45:25.40

サイトの速さが実力を表しているのでは？
滅茶苦茶速い。
これもゆにけーじ？

**デフォルトの名無しさん** · 2022/10/16(日) 02:49:01.03

サイトの速さ？お前ベンチマークしたの？
誰もアクセスしないし、あれくらい普通でしょ。

ユニケージは大規模アクセスに耐えられないから
無印とかでシステム停止に陥った。

**デフォルトの名無しさん** · 2022/10/16(日) 03:01:22.69

実際速いんだから十分では？

**デフォルトの名無しさん** · 2022/10/16(日) 03:07:12.94

だからアクセスが集中した時は遅いってｗ
それにあれぐらいの速度であれば
WordPressとかでも出せる

**デフォルトの名無しさん** · 2022/10/16(日) 07:55:00.17

>>37
論破されてて草
諦めなよ

**デフォルトの名無しさん** · 2022/10/16(日) 11:22:41.59

>>39
どこがだよ、君は馬を見て鹿と言っている

**デフォルトの名無しさん** · 2022/10/16(日) 11:42:45.97

>>40
それってあなたの感想ですよね

**デフォルトの名無しさん** · 2022/10/16(日) 11:58:47.43

>>41
僕の感想であり真実ですね
僕には真実を見抜く目があります
僕の目にはユニケージはゴミと映ります

**デフォルトの名無しさん** · 2022/10/16(日) 13:27:51.83

>>42
もし本当にユニケージがゴミなら
こんなに関連書籍が出版されているはずがないだろ
人気なんだよ

**デフォルトの名無しさん** · 2022/10/16(日) 13:54:38.22

過去のバージョン管理ツールで肥大化したプログラムに泣かされた人は少なくないだろう

**デフォルトの名無しさん** · 2022/10/16(日) 15:11:20.87

技術力は高そう。

**デフォルトの名無しさん** · 2022/10/16(日) 15:21:36.59

サイトがメチャ速い。
これもユニケージで出来てるの？

**デフォルトの名無しさん** · 2022/10/16(日) 16:01:56.72

>>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使った方が良いと思うんだよね

**デフォルトの名無しさん** · 2022/10/16(日) 16:04:36.25

ユニケージが人気という風聞は聞いたことがないし
ユニケージの関連書籍が多いとも思わないな
書いてるのは全部USP研究所だもん、自作自演だよ

**デフォルトの名無しさん** · 2022/10/16(日) 16:16:47.84

DBを使えば処理がわかりやすくてクラウドへの移行もやりやすい
BigTableやRedshiftを使えば億単位の処理もサクサクできる

ユニケージのデメリットは
・可読性が低い
・保守性が低い
・クラウドのサービスを活用しづらい
あたりかな

ユニケージを推進しようとするのは心理学的にはNot Invented Here、NIH症候群(自前主義)のように思われる

**デフォルトの名無しさん** · 2022/10/16(日) 16:35:23.55

>>48
自作自演でも、シェルスクリプトマガジンとかも出してるし
ちゃんとした出版会社でしょ？そこは凄いと思うよ。

**デフォルトの名無しさん** · 2022/10/16(日) 16:43:04.67

色んな人がユニケージ関連の書籍を出版するならユニケージが人気ですごいと思うけど
自作自演の出版を人気だとは思わないしすごいとも思わないな

**デフォルトの名無しさん** · 2022/10/16(日) 16:44:20.08

ユニケージは技術的にもそんなに良いものじゃないのは上に書いた通り

**デフォルトの名無しさん** · 2022/10/16(日) 17:23:54.64

>>51
本を出版するのは凄いことだと思いますが？

どこかの大手にお金を払って出版してもらっているわけではなく
会社自体が出版会社を兼ねているわけでしょう？

出版会社としては小さいかもしれませんが、例えば
アスキーとかインプレスみたいなものなわけで
どんな会社でもできることではありませんよね。

**デフォルトの名無しさん** · 2022/10/16(日) 17:30:04.37

ひろゆき並みに議論のすり替えが酷いな

**デフォルトの名無しさん** · 2022/10/16(日) 17:30:37.00

このスレはユニケージがクソなことを語るスレです

**デフォルトの名無しさん** · 2022/10/16(日) 18:32:19.11

ユニケージはノンコードと同じ理念と考えて良いですか？

**デフォルトの名無しさん** · 2022/10/16(日) 18:49:05.23

>>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 | # ２つのファイルの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 - ｋ # 出力する

やすい　コストが安い・プログラムが易しい　開発コスト4分の1
はやい　開発期間が短い・処理が速い　開発期間4分の1、処理速度10分の1
やわらかい　どんな性質のデータも取り扱える　変化、異種、重複、不確定、履歴、etc
ながつづき　データもプログラムもコピーだけで移植可　システム寿命25年以上

高速なデータ処理を行います。1000万件の集計が0.67秒、ソートが2.29秒！
こんなすごい開発手法、見たことないでしょう？

**デフォルトの名無しさん** · 2022/10/16(日) 19:49:11.97

やっぱりユニケージは最高です

**デフォルトの名無しさん** · 2022/10/16(日) 23:12:51.81

>>57
このクソみてえなコマンド群はなんなの

**デフォルトの名無しさん** · 2022/10/16(日) 23:32:34.16

>>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

**デフォルトの名無しさん** · 2022/10/16(日) 23:33:03.86

>>59
何やってるかわからんよね

**デフォルトの名無しさん** · 2022/10/16(日) 23:36:14.68

やっぱりSQLの方がわかりやすい

**デフォルトの名無しさん** · 2022/10/16(日) 23:38:09.89

エイリアス使わないとSQLも何気に見にくいなぁｗ

**デフォルトの名無しさん** · 2022/10/16(日) 23:45:01.46

>>57
すごい！
最高じゃないですか！

**デフォルトの名無しさん** · 2022/10/17(月) 01:18:10.64

>>61
千で割るからdivsenだよ。わかりやすいやろ
このセンスが海外でもオオウケ
https://unicage.eu/

**デフォルトの名無しさん** · 2022/10/17(月) 02:17:23.76

チュクバイは名前がダメだな
コマンド名の品質が低い

パイプラインの本質は宣言的プログラミングで目的がわかりやすくなることだ、しかしチュクバイはわかりにくい、抽象化に失敗してるとしか思えぬ

ユニケージは負の遺産

**デフォルトの名無しさん** · 2022/10/17(月) 02:20:03.55

SQLは宣言的プログラミング言語、ユニケージのパイプラインは所詮SQLの劣化版でしかない

**デフォルトの名無しさん** · 2022/10/17(月) 08:00:02.33

>>66
TukubaiはUNIXのコマンドの拡張。だから処理速度も高速。
UNIXコマンドは優れている。優れたコマンドは短い名前を持つ
名前が短いということはTukubaiを使うとコードが短くなる
コメントを除けばSQLなんかよりも圧倒的に短い
だから開発コストも4分の1になるというわけ

**デフォルトの名無しさん** · 2022/10/17(月) 09:35:23.06

やっぱりユニケージ最高です

**デフォルトの名無しさん** · 2022/10/17(月) 09:41:38.06

ユニケージがOSに近いところで動くとか本気で言ってるんだろうか