176(4): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 06:54:51.14 ID:Eh77ZCvU0(1/15) AAS
考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。
俺はツールはあくまでアプリの品質を上げる手段だと思ってる。
ここまではおそらく共通なのだが、問題はこの先で、俺は重要な順に、

A. アプリそのものの品質。つまり必要な機能に深刻なバグがないこと。コードの品質がこれに直結する。(コードが本体)
B. 使いやすさ。簡単は正義。使えない機能は存在してないのと同じ。直感的に使えればドキュメントすら必要ない。
C. 持続性。つまり自分が使いたい期間(未来)中ずっと使えるか。

なんだが、Git陣営は全く逆でC>>B>>Aの順に見える。
それはこのスレ内でも散見され、俺は釣りだと思っていたが、マジっぽい。つまり、

C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。これを取り持つのがツール(ツールやcommitメッセージが本体)
B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。

Git陣営はマジでコードの品質を上げる努力を何一つしてない。具体的には、

・regressionテストを1本も流してない。
・レビューも全くしてない。(マジで、見た瞬間落とされるコードを素通し)
・CodeOfCoductは重要だが、CodingRuleは要らない。

CodeOfConductは最近のポリコレで生まれた、「人の」振る舞いを規定するものだ。
これに対してCodingRuleは「コードの」振る舞いを規定するもので、
CodingRuleなしでCodeOfConductだけってのは、コードはどうでもいい、問題は人だ！と言ってるわけだ。
『人さえいれば、全て何とかなるんだ！』という思想だ。

ただ俺からすると、見る限り完全に「善意のただ乗り」であって、
少なくともコードの品質を上げる努力してないと協力する気にならないよ。
(ITがいくら自動化しても、最終的には人なのは事実としても、コードの質を直接的に改善する努力を全くしないのは不味いだろ)

177(3): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 06:55:24.88 ID:Eh77ZCvU0(2/15) AAS
俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。つまり、
仕様が簡単で直感的なら、ドキュメントを整備するまでもないし、
バグがなければ、後は「十分動く」程度のメンテで済む。だから最初から出来る限り品質の高いアプリを投入すべきだ。
ここら辺は「伽藍」では共通認識のはず。『コード/仕様さえよければ、全て何とかなるんだ！』的な思想だ。

ただここら辺を「バザール」でひっくり返したから話題になったわけだが、やっぱこれは違うよな～とは思うよ。
これって「善意のただ乗り」の仕方が世界一上手かっただけで、みんながこれをやり出したら回らないよ。

172(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 23:27:07.46 ID:403mRijK0(9/9) AAS
>>162
作ると言ってるだけで作らず、皆が興味をなくすのを待つと思っている
ここで偉そうにするだけならそれで十分だからな

本当に作ると言うなら進捗状況を週に一度くらい公表すればいい
そのためにスレを立ててトリップを付けてでもいいしツイッターとかでもいい
実際にプログラムを書きはじめたらそれもどこかで公開する
進捗状況が分かるようにな
来年3月末目標ということで >>101

185(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 12:40:13.79 ID:Eh77ZCvU0(4/15) AAS
>>184
全通しならレビューの意味がない。よく分からん所でなあなあでウェットなんだよ。

例えば>>58の中盤以降、「どうやってOSSを飼い慣らすか」になっててすさまじく気持ち悪い。
これはタイトル「オープンソースソフトウェアの育て方」からしてそうではあるけども。
しかも書いた奴がCVSにも相当関わってて、Subversionも率いてた奴だってのがかなりキテる。
そして同様の雰囲気をGitからも感じる。

俺は「自分が使ってるツールにバグがあるのは自分も困るので、協力したい」とか、
「自分もそれが欲しいから」という、
個人の利益の追求の方向が偶々揃った程度で連携すべきで、それで十分だと思ってるんだよ。
だから「売れそうなら作るし、欲しければ乗ればいいし、要らないなら無視でいい」になる。(166)
勿論解消も各自の自由で、売れなさそうなら作らないし、ゴミなら使わない、でいい。
極めてドライな連携だ。
そして一般的に匿名掲示板はこの程度だから、俺は気に入ってる。

対して上記本やGit、いかにcontributerを手なずけてコードをタダで貰うか、みたいになってて、本当に気持ち悪い。
それがLinusが世界一上手かったことではあるし、それが成立するという驚きが「伽藍とバザール」だけども。
>>95の内容も若干キモイ。
Linusの個人崇拝になってて、Linus自身はそれにちょっと困ってる、ってのは分かる気がするよ。

コードはコードの内容だけで評価するべきで、
誰が送ってきたとか、これまで彼がどれほど貢献したとか、そういうの、勘案すべきではない。
落とすべきコードはドライに落とすべき。
CodeOfConductでポリコレ宣言せずとも、こんな事はみんな普通にやってきたことだよ。

が、まあ何か思惑はあるのだろうよ。
究極のコードクレクレ君を見せてやるぜ！！！と言われてる状態なので、とりあえず見物だ。

191(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 18:44:25.19 ID:Eh77ZCvU0(5/15) AAS
>>190
俺の価値観からすると、ツール使えるだけで、
肝心の、あのソースコードと開発体制と仕様のヤバさに気づけないのは、本末転倒だと思うけどな。

まあ平行線だからいいよ。決着はforkで、だ。
俺が作るツールは、君ら向けではないし、実際君らには無価値だよ。
そもそもGitを使ってるだけで、Gitを使う為のアプリではないからね。
(これが誤解の元だったから、Gitと冠するのは止めようかと思案中)
だから第一弾で君らが死ぬことはない。
Gitを殺せるとしたら第二弾以降だが、まあ、これも無理だろうよ。これが目的でもないし。
むしろ、Gitを目的外使用してる連中を引き受けるので、お前らは居心地がよくなるかもしれん。
Gitはmerge専用機としてはよく出来てるよ。
しかし一般開発には、通常commit(親が一つのcommit)の方が断然多くて、今使ってる連中の大半もそうだと俺は思うけど。

それはさておき、多分Gitや他気持ち悪い系OSSが維持出来てるのは、
初音ミクの時に言われた、「ヘタウマ」じゃないかと。
日清カップヌードルでも言われてるが、要は「チョイ足し」したくなる絶妙な「ヘタウマ」ならソースコードも集まりやすい。
Linusが書いた完全無欠のコードでは、誰も手が出せないからね。
だからソースコードがある程度ゴミなのは、成功してるOSSの宿命なのかもしれん。
界隈よく知らないけど、例の鳥の詩(国歌)、完成してる感があって2次が少ない(ほぼ無い)と聞くし。

197(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 20:22:53.70 ID:Eh77ZCvU0(6/15) AAS
>>195
> その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
> それをベースにするってことだろ
違うぞ。既に書いたが>>118,142
というかね、俺はその辺お前らGit勢とは違ってポリコレはしない。
コードに政治は持ち込まない。使えれば使う、程度だ。

SQLiteだとGitの再開発が必要になるのが無駄だ。SVNの方が良ければ乗り換えるかもだが。
(というかバケツ的使用感をSVNが提供してたらそれで終わり、俺がアプリ作るまでもない。
これって今無いのか？
逆にSVNもGitと同様政治的で、バケツなんて提供してヤラネ、学習して使え！
なら俺がバケツアプリSVN版も売れそうなら作るかもだが)

204(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 21:39:36.54 ID:Eh77ZCvU0(9/15) AAS
>>201
それ、前にも少し気になったのだけど、
Git屋はまだ本が主流なのかい？

Web系だと本ではどうにもならないから、ここで初心者が「いい本はありませんか」と聞いてきても
「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
俺自身、もう本屋に何年も行ってない、に近い。

だからサル先生とか馬鹿にしてるのも、よく分からない。
紙かWebかなんて、どっちに書くかでしかないだろ。
紙媒体なら信用出来るなんて時代はとうに過ぎてる。
そもそも紙媒体の編集者はその選別眼を持ってない。
お前らがあれが糞コードだと理解出来ないように、本職以外の奴が本職の専門家向けに情報を選別するのは無理なんだ。
そして連中はただの印刷業だから、ある意味売れそうなら印刷するだけなんだよ。
だから本当に酷い内容でも本になってたりする。
ただ問題は、初心者にはそれが酷いとは分からないんだよ。

だから俺は適当にググって評判が良さそうなところを読むだけ。
Gitの場合は確かにBook読めではあるが、別にサル先生を馬鹿にする必要はあるまい。

206(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 21:59:49.24 ID:Eh77ZCvU0(10/15) AAS
>>205

205： 連中がキモイとか言うなら、そいつらが作ったコードも使うべきではない
俺： コードにポリコレは持ち込まない。誰が(キモイ連中)が作ったかは関係なく、そのコードが正しく動く範囲なら使う。

お前らポリコレ過ぎる。コードはコード、作成者がキモかろうが関係ない。
というか、まあ、キモイとか言うなら使うな！というのがCodeOfConductだから、
205の姿勢はGit的には正しいのかもしれんが、とにかく俺はそうじゃない。
(この点も俺はGit勢には馴染まないから、やっぱ遠巻きに見守るべきだな。変に突っ込んでたら大騒ぎだったかもしれん)

しかしこの勢いだと、GPLv4にはポリコレが入って、「キモイとか言う奴には使わせない」とかになりそうだな。
笑えねえ。

211(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 22:17:53.79 ID:Eh77ZCvU0(12/15) AAS
>>205
ちなみに技術的な話をすると、
> gitのコードはしっかりしているということだろ
これは根本的に違ってて、要するに俺が楽したいだけなんだよ。

内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。(POSIX君はこの点を問題視してるわけ）
そして外部ソフト自体がバグってても勝手に直してもらえる。
寄っかかることに抵抗がなければ、寄っかかった方がユーザーにも制作側にもメリットがあるんだよ。
(勿論囲い込みは出来なくなるが、最初からそんなのする気ないし）

デメリットは、その外部ソフトのバグもユーザーには俺のバグにに見えるから、俺がバグ対応窓口にさせられる可能性があること。
俺のバグなら致し方ないが、外部ソフトのバグなんて対応してられない。だから安心出来る範囲でしか使わない、ということ。
要は全部楽する為の方策であって、お前らみたいにポリコレまみれではないんだよ。

214(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 22:43:28.98 ID:Eh77ZCvU0(13/15) AAS
>>212
それはベースにしてるわけではないんだよ。（つか俺がそう言ったっけ？なら訂正だが)

多分OOPの基本すら理解してない君達には通じないが、繰り返すと、
そこは即交換可能なんだよ。
少なくともGitとSVNはほぼ自動的にそうなる。（一般的に普通に組めば自然とそうなる）
SQLiteだとGitやSVNに入っているコードまで自前で書く必要があるから面倒だが。(だからこれはやる気なし)

ベースではなく、外注なんだよ。必要とあればすぐ交換可能だ。

つっても、通じないだろうけどさ。

101(5): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:52:44.85 ID:h41UD2lS0(4/29) AAS
>>89,94,95
全部読んだ。なかなか面白かった。(89はコメントも全部読んだ)
君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。
ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。

今考えている構成をざっくり言うと以下

・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)
　十分売れてる限り保守してやんよ(その必要すらないほど単純なアプリだが)
・プロプライエタリで伽藍開発。バザールなんてとても無理。コードは俺が書くから、お前らは使い勝手をフィードバックしろ。
・GitBucket(仮称)、Gitと付けたら不味いのなら考え直す
・コンセプトは、「何も知らなくても使える『全自動完全履歴保持バケツ』」
　よって仕様は限りなく簡素化し、それ以上やりたければDBはgitだからgitアプリ使え、とする
・diffは取れるがmergeは直感的GUIがないので無理。が、主にバイナリを保存する連中には全く関係ないし。
・branchはディレクトリに割り当てて手動で。というより、git内にcommit履歴が保持されてないのでbranchの識別が出来ない。

199(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 20:32:39.63 ID:Eh77ZCvU0(7/15) AAS
>>198
>>101,102

219(3): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/13(日) 23:35:45.59 ID:Eh77ZCvU0(15/15) AAS
>>218
ベースとは言ってないだろ。
フロントエンド/バックエンドとは言ってるが。
それらはまるで意味が違う。
（というのも通じないからもう終わりにするが）

ちなSVNで最初から組むことも問題なく可能だよ。それがOOPでもあるし。
ただSVN確認するのが面倒なので、とりあえずGitで行くってだけで。
(SVNみたいな集中型は鯖立てが必要な可能性があるのでとりあえず敬遠《未調査》)

よく分からんけど、もしGitがお前の持ち物なら、ライセンス変更すればいいんじゃね？
お前の持ち物でもないのに文句言ってるんだったら、お前だいぶ狂ってるよ。
俺からみたら、Gitのコードが糞なのも、Git陣営の動きがキモイのも、事実だよ。
そういう俺が狂ってる、とお前が思うのも自由だが、コードについては第三者に判断可能だから、
お前の周りでCを「きちんと」書ける奴が居たら、今回の顛末見てもらえ、と何度も言ってる。