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
元のコードを見ろ
可読性なら日本語のコメントで解決できる マジックナンバーだらけのコードを書かなければいい
省略した関数名つけなければいい
コメント見なくてもコード見ればわかるのが可読性の高いコード
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秒で処理できるとか、
そんな遅い自慢をしてたよ サイトの速さが実力を表しているのでは？
滅茶苦茶速い。
これもゆにけーじ？
サイトの速さ？お前ベンチマークしたの？
誰もアクセスしないし、あれくらい普通でしょ。
ユニケージは大規模アクセスに耐えられないから
無印とかでシステム停止に陥った。
だからアクセスが集中した時は遅いってｗ
それにあれぐらいの速度であれば
WordPressとかでも出せる
>>41
僕の感想であり真実ですね
僕には真実を見抜く目があります
僕の目にはユニケージはゴミと映ります >>42
もし本当にユニケージがゴミなら
こんなに関連書籍が出版されているはずがないだろ
人気なんだよ 過去のバージョン管理ツールで肥大化したプログラムに泣かされた人は少なくないだろう
サイトがメチャ速い。
これもユニケージで出来てるの？
ユニケージが人気という風聞は聞いたことがないし
ユニケージの関連書籍が多いとも思わないな
書いてるのは全部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 | # ２つのファイルの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秒！
こんなすごい開発手法、見たことないでしょう？ >>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 チュクバイは名前がダメだな
コマンド名の品質が低い
パイプラインの本質は宣言的プログラミングで目的がわかりやすくなることだ、しかしチュクバイはわかりにくい、抽象化に失敗してるとしか思えぬ
ユニケージは負の遺産
SQLは宣言的プログラミング言語、ユニケージのパイプラインは所詮SQLの劣化版でしかない
>>66
TukubaiはUNIXのコマンドの拡張。だから処理速度も高速。
UNIXコマンドは優れている。優れたコマンドは短い名前を持つ
名前が短いということはTukubaiを使うとコードが短くなる
コメントを除けばSQLなんかよりも圧倒的に短い
だから開発コストも4分の1になるというわけ ユニケージがOSに近いところで動くとか本気で言ってるんだろうか
>>70
これかな？ひどいという意味で面白いねｗ
これが「超高速開発手法」です。です!
https://togetter.com/li/960555
> 日銀のペーパー読んでたら、頭がおかしいとしか思えない記述があったので晒しておく
> 「超高速開発手法については、例えば、Linux のオペレーティングシステム（OS）に直接命令を出す「シェルスクリプト」などが挙げられる。」
OSに、直接命令を出す・・・シェルスクリプト・・・？
> このフリーソフトを使えば、Oracle Database や DB2 といったミドルウエアを介在
> させることなく、ハードウエアの性能をそのまま利用することができる。
ミドルウェアを介在させないからハードウェアの性能を利用できる・・・？
どういう理屈？ｗ >>70
まあ近いんじゃない
コマンドはネイティブコードだしパイプもOSの機能を使うし
ファイルもOSの機能だし
業務アプリでそれに価値があるかは疑問だけどね OS に近いところで動作ってこれか
OSに近いところで動作するってどういう意味？
https://www.usp-lab.com/qa.html
ユニケージ は、DBMS よりもより OS に近いところで動作するため、
自由にファイルを配置したり、コマンドを作成することによって、
シンプルな処理から複雑な処理まで、幅広く対応することが可能です。 >>74
ユニケージじゃなくてもOSに近いところで動いてるでしょ？
特にミドルウェアはOSにシェルスクリプトよりもOSに近いところで動いている。
シェルスクリプトは、コマンドを介在させないといけないから遅いでしょ
だからハードウェアの性能をそのまま利用できない シェルスクリプト → ユニケージ（ミドルウェア） → OS
だからユニケージは遅い
>>76
どうなんだろうね、DBはOSのファイルシステムをバイパスして独自に
データ管理したりするからOSに近いというかOSを超えちゃってる感がある
あとはJavaや.NETなど仮想マシンで動くのもOSから少し遠い気がする
インタプリタは良いのかと言われるとシェルスクリプトもインタプリタだし
そう考えるとOSに近いの意味がよくわからんな
OSにはファイルというデータを管理する仕組みがあって
パイプというコマンドをつなぎ合わせる仕組みがある
それらを使ってアプリを作ることをOSに近いと言ってるだけだと思うんだよね 近いとか遠いって意味が分からない
アプリもシェルコマンドも同じ階層じゃね？
つか、シェル介入する分シェルコマンドの方が遠くね？
>>77
遅いのはそうだと思う
速さが要求されるシステムプログラミングでパイプが推奨されてるのなんて見たことがない
速さを重視するならパイプではなくてループ文を使ったが良い パイプは処理を抽象化してわかりやすくするのを目的に使うものだけど
ユニケージはそれにわかりにくいコマンドを載せて使ってるのが
なんかこうやってることがツギハギというか支離滅裂な感じがある
phpで普通にプログラム書いた方がわかりやすくて速い気がする
>>78
確かOracleとかデータベースをファイルシステムにしていたよね？
今もやってるのか知らないけど
> シェルスクリプトもインタプリタだし
> そう考えるとOSに近いの意味がよくわからんな
多分だけど、
UNIXにはたくさんのコマンドがある
→ そのコマンドはOS
→ ユニケージもコマンド作ってる
→ コマンドはOS！ユニケージはOS！（んなわきゃない）
→ OSだからカーネルに近い！（んなわきゃない）
→ カーネルは中心なんだから速い！（んなわきゃない）
この程度の素人思考だと思うよｗ
そもそもあそこの社長？ダイエーかなんかで
SIとかCOBOLの開発のそういうのに関わってきた人だし
いわゆるSヨで技術的なことはほとんど何も理解してない思う
「ふんふん、なるほど、そういうことだな。UNIXは凄いんだな。よしUNIXは凄いぞ！」 既存のプリミティブな処理をつなぎ合わせれば何でも出来る
ってのわ分かるが、使い勝手が悪いからアプリとか作るんだよなぁ
得にUI
>>81
> ユニケージはそれにわかりにくいコマンドを載せて使ってるのが
> なんかこうやってることがツギハギというか支離滅裂な感じがある
いや、一貫性はあるよｗ
「UNIXは凄い！UNIXの真似をしよう！」
lsとかコマンド名短いでしょ？
これが正しいやり方だって思い込んじゃって真似してるだけなの
新しいことを取り入れることができないから
オープンシステム全盛期のUNIX時代を今も続けているだけ
新しいことを取り入れることができないから
シェルスクリプトはローコードプラットフォームだとかいって
古いものを延命させようとしてるだけ なんだかバッチ処理とかやってた昔の人が当たり前にやってた事を再発見してるだけだしなぁ
>>83
UNIXはデータベースなんか使ってなかった
全部ファイルでやっていた
だからOSの基本機能だけで作ろう
まあ、これが基本的な発想だろうね。
もういやだ、アップデートの更新作業はもういやだ。
シェルスクリプトしかできない人たちなので
ミドルウェアとかを使うことができない コピペで人が貼り付けするより、シェルスクリプト組んで実行させた方が速い、くらいの感じ。
>>85
どっかからの聞きかじりでパイプは凄いって聞いて
ほら、初心者が配列とかクラスとか正規表現とかデザインパターンとかを学ぶと
全部それだけでやろうとするでしょ？
あそこの社長は、それと同じでパイプを何段も繋いで
メーカーの人にプログラミングの基本ができてないと笑われた
だからパイプに執着してる
あとは他の言語などですでに実現されていることを、
シェルスクリプトだけで頑張って出来ることを証明しようとしてるだけ シェルスクリプトのバッチ処理が
コボラーのバッチ処理と
うまくマッチしたんだろうなって思ってる
RDBMSという新しい概念を理解できず
コボラーのやり方を続けてるだけ
本来はプログラムを組む必要が無い簡単な処理
ソートするとか、単語抽出とか、そんな事やらせる目的だったんだけど
ガッツリシェルスクリプトだけで複雑な処理させるのは単なる自己満足でしか無いよ
しかもメンテナンス性最悪だしな
シェルスクリプトは速いとか言いながら、
お前らはC言語？でコマンド作ってるじゃん
速いのはシェルスクリプトじゃなくてC言語じゃんっていう
ツッコミもあるしね。ほんと技術を理解してんのかこいつらって思う
そりゃあ単機能だから個々の処理は速いと思うのも無理は無いがw
POSIX原理主義はそれに輪をかけて意味不明で
ユニケージのコマンドはPOSIX準拠じゃねーじゃんってね
C言語で作られていればPOSIX準拠ですっていうのなら
じゃあ大概のコマンドはPOSIXコマンドじゃなくても
POSIX準拠じゃねーかってね
あと交換可能性とか言ってるけど、
お前らが作ったコマンドは交換可能性を満たしてねーだろと
そういやユニケージ vs mysqlの速度比較でユニケージのほうが速いと錯覚させるために
ユニケージコマンド vs mysqlコマンドで比較していた例があったよなｗ
そりゃSQL実行するたびにmysqlコマンド叩いてれば遅いだろうよ
そんな使い方しねーよ。シェルスクリプト使うから
mysqlコマンド叩くしかねーんだろうが
ユニケージは遅いし信頼性がないし、挙げ句コードの保守性がない
ネットワーク系って、乗っ取りとか考慮してシェルコマンド名変えたりしてんだっけ？
POSIXに準拠してるだけで可搬性が保証されるわけでもないだろうに
GitHubクソ使いづらいんだがなんで日本仕様のGit連携できるサービスねぇの？
Source Code Control System（SCCS）いいよね。
俺は使った事がないけど。
github に
git push -f しちゃだめって聴くけど
そうでもないよね？
