日常の進捗履歴記録ツールWitBucket(仮称)検討中

レス数: 229

概要: 日常の進捗/履歴記録/バックアップツールWitBucket(仮称)の製作を検討中です。 欲しい機能/実装等について意見あればどうぞ。 (長さ制限によりスレタイは一部略) (カッコ内はGit19スレ内の参考レス番) ...
No.1
日常の進捗/履歴記録/バックアップツールWitBucket(仮称)の製作を検討中です。
欲しい機能/実装等について意見あればどうぞ。
(長さ制限によりスレタイは一部略)
(カッコ内はGit19スレ内の参考レス番)
詳細: Git19:
https://mevius.5ch.net/test/read.cgi/tech/1667720427/101-102

経緯: Git19:
https://mevius.5ch.net/test/read.cgi/tech/1667720427/59-

全レス: Git18:
https://mevius.5ch.net/test/read.cgi/tech/1650651945/633-

【コンセプト】
・ゴミ箱の様に簡単に操作出来、何も知らなくても使える『全自動完全履歴保持バケツ』(101)
No.2
【目標仕様】
・Gitを全く知らない人でも使える。
・Gitのビュワーとしても多分使える。ライタとしても使えるはずだが勧めない。
・中身の改変/消去を簡単に出来るようにする。(142)
・Gitツールではないので、Gitのフル機能へのアクセスは提供しない。
・diffは取れるが「ファイル内の」mergeは直感的GUIがないので実装しない。(101,127)
・branchは現ブランチをパスと共に保存するのみ。(103,112)
・デスクトップ等に転がしてるファイルも明示的に指定すれば保存される。(109)
【実装】
・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)(101)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)(101)
・プロプライエタリ。コードは俺が書く。使い勝手のフィードバックを希望。(101)
【開発意図】
・後で確認出来ればいい程度の人にはGitは学習コストが高すぎるので、無学習で使えるアーカイバを用意する。
・保存先はGit。これにより、gitや外部ツールを使うことも可能になる。(211)
・Gitで間違った物をcommitして結局全部作り直した、みたいな話が散見されるし、
 実際俺も困ったことがあったので、簡単に改変したり消したり出来るようにする。
・この機能でGitのリポジトリも改変出来るが、
 俺自身がGitの仕様に詳しくない為、非互換の部分が発生するかもしれないので、勧めない。
 (この意味ではバグだし、確認出来ればgitになるべく合わせるようにはするが)
・ビュワーとして使うだけなら安全。gitをゴミ箱GUIで閲覧出来るようにする。
【日程】
・作る場合は、2023年3月末リリース目標。(101)
・広告収入目的の商用アプリであり、売れそうにないと判断した場合はそもそも作らない。(202)
・electron/Windowsストア/広告アプリ/他全Windows版Git/Saplingについての調査が必要。(102,299)
No.3
【第二弾(完全に未定)】
・Gitに欠けている機能を補完する。
・commit/rebase履歴が無いので、付加する。(111,274)
・Viewでrebaseする。(多分saplingもこれを目指している)(331)
【名称について】
・GitBucketがよかったが既にあるのでボツ。(126)
・Gitと冠するのはGitツールだと誤解を招くようなので、外すべきか?(191)
・しかしやはりGitの方が分かりやすいか?ならばGitPailが確かに良い(244)
・Linusと同様に3音3文字でunixコマンドと被らず、
 馬鹿向けgit(馬鹿)で馬鹿の最上級を探したが、無いので、一周回して
 WitBucket(天才バケツ)。中身がGit感もある。
 GitツールではないのでGitと付けないくらいが丁度よいと判断した。
 Gitxxxxとするなら、GitPail。検索的に有利なこちらにするかも?
No.4
四次元ポケット
No.5
Gear It Technologyみたいに頭文字合わせるとGitになるみたいにするとおしゃれだぞ
No.6
個人でするなら、自分が使うものでないと続かないよ
No.7
>>4

実はそれも考えた。
俺が欲しい物ってなんだろう?と思ったときに、一番分かりやすい表現がそれだったから。
ブッ込んでおきさえすれば、あとは手で探れば取り出せる、的な。
ただそれって、
現物(WitBucket)→四次元ポケット、にはなるけど、
四次元ポケット→現物(WitBucket)、にはならないんだな。
「四次元ポケット」と聞いてきた連中が想像するのはもっと違った何かで、Gitのフロントエンドではない。
というわけでボツ。
あとちなみに、Gitxxxxで考えたのは、
GitChest:大道具箱
GitCasket:小物入れ、宝石箱、
GitCan:can(出来る)とのダブルミーニング
GitBin:binもこの界隈では違う意味になってしまうが、can/bin共に蓋付きなので雑に放り込んでおけるイメージがないのでボツ
GitBox:大切にしまうイメージでボツ
GitTrunk:同上
GitBasket:ザルは漏れそうなのでボツ
Pailは俺自身知らなかった。そういえばペンキ缶のことをペールって呼ぶけど、あれ、正式名称だったんか!ってな具合。
ただ、雑に放り込めるイメージはあるから、(その単語を知ってる人には)Gitxxxxでは一番合ってると思う。
それから、名前ぐらいあとで決めろ、とか思う連中は、先人の知恵に学ぶべきだよ。(賢者は歴史に学び、愚者は経験に学ぶ)
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E5%90%8D%E5%89%8D%E9%87%8D%E8%A6%81/

最初読んだとき、俺も、Matzよ、もうちょっとましなことは書けなかったのか?と思ったけど、今はこれは凄く納得してる。
少なくとも、自分が気に入らない名前は付けるべきではない。長期的に愛せなくなるから。
No.8
>>5

その発想はなかった。が、GNUもそうだし、考えてみるべきだな。
・馬鹿でも使える
・ブッ込んでおくだけ
・中身はGitであると薄々見える
と名前を聞いただけでイメージ出来る案があれば募集。
No.9
>>6

それはその通り。
なので「広告」付けて金銭で俺自身を釣る。
多分自分でもそこそこ使うが、Gitに慣れたら問題なくなってしまうのだと思うんだよ。
それがGitスレの連中なわけで、多分俺もそうなる。
俺自身が欲しいのは第二弾の方で、
こちらはGitには無いが俺には必要な機能を実装するから、俺自身が使い続けることは確定してる。
(ただし第二弾自体が未確定、それ以前に第一弾も未確定、
そもそもSaplingが実装済みな可能性大なのでこちらもよく確認して、になる)
No.10
Git In Trash
No.11
Garbage in Trashbox
Garbage is Trash
No.12
>>10

それ言うならGNUばりに
GIT Is TrashBox
なんだろうけど、これだと通称も略称もGitなのが駄目だな。
あと、「ゴミ箱」ではどうしても「捨てる」感を払拭出来ないのが問題だ。
片づけるのが面倒だからとりあえず入れておく「ガラクタ入れ」(=最初から捨てる気はない)が使用感として正しいので。
>>11

と(上記のように)思ったけど、先に言われてしまった。
まあ略したら実はGitってのは良いが、この長さだと通称もGitになりそうなのが不味い。
多分対等な言葉を並べてるのが悪い。
Great Ineligible's Trail (偉大なる馬鹿の軌跡)
とかだと通称「トレイル」で、「トレイル付けたか?」とか使われるからまだ行ける。
しかしこれもGit公式
> "Goddamn idiotic truckload of sh*t"
>
https://git.wiki.kernel.org/index.php/Git_FAQ#Why_the_.27Git.27_name.3F

と似たようなものではあるが。
No.13
スレ主はgitを使いこなせているんだろうな?
No.14
gitどころかプログラミングの経験があるのかどうか
No.15
Microsoft の SharePoin で既にバージョン管理できてないか?
No.16
うちのオフィスにはパワーポイントは入ってたけどシェアポイントは入ってなかったわ。
残念。
No.17
>>15

全く知らんが、見る限りただの豪華版ファイル共有システムのような。
これで任意の履歴を探索出来るのなら、十分ではあるが。
というか、WitBucketはこの辺の「履歴探索出来ればOK」程度の連中を相手にしてる。
同一ファイル内のmergeなんて、ほぼ必要ない連中向けだ。
ちな、お前ら本当に「任意のファイルを任意のタイミングで任意に編集出来る」開発スタイルで、
mergeも日常的にやってるのか?
それはチームの腕前が『上側に』揃ってる必要があって、
上手く回ってるのなら素晴らしいが、下手すると余計悲惨なことになるので、
一般の会社(新人からベテランまでの混成部隊)ではかなり無理だが。
ただサイボウズ(だったと思う)のインタビュー読んだとき、
ああこいつらは(俺の想定している)一般とは違うフローなのだな、とは思ったので、
連中は上手く出来てるのかもしれんが。
No.19
>>18

そこから辿れる7ページ全部読んだ。
確かにこれで良い。履歴の部分が欲しいだけ。
> ヒント: チームで共同編集機能を使用する場合は、
> ライブラリ内で他のユーザーが共同編集しているものと同じ名前のドキュメントを誰かが誤ってアップロードしてしまった場合に備えて、
> 少なくともライブラリでメジャー バージョン管理を有効にすることをお勧めします。
> そうすることで、変更内容が失われた場合でも、ドキュメントの前のバージョンに復元することが可能になります。
>
https://support.microsoft.com/ja-jp/office/%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%86%85%E3%81%AE%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A2%E3%82%A6%E3%83%88-%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3-%E3%81%BE%E3%81%9F%E3%81%AF%E5%A4%89%E6%9B%B4sharepoint%E3%81%99%E3%82%8B-7e2c12a9-a874-4393-9511-1378a700f6de

> 定期的に、ドキュメントを編集および保存Officeします。
> すべての編集と保存で新しいバージョンが作成される場合があります。
> たとえば、頻繁に編集を保存する場合、各新しいバージョンでは、個々の編集ではなく、ポイントインタイムがキャプチャされます。
> これは、自動保存 が有効になっている場合に一 般的です。
>
https://support.microsoft.com/ja-jp/office/%E3%83%AA%E3%82%B9%E3%83%88%E3%81%A8%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%A7%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%81%AE%E3%81%97%E3%81%8F%E3%81%BF-0f6cd105-974f-44a4-aadb-43ac5bdfd247

ただ5000しか保存出来ないのは問題だから、縮退して欲しい。
自動保存等の割とどうでもいい奴はコミットメッセージ(SharePointではチェックインコメント)が入ってないから、
それらは直近100件越えたら自動的に縮退でいい。いやなら何かしら入れとけ、で十分だ。
マニュアルでバージョン番号を上げた場合は全保持(縮退無し)で。
No.20
> Microsoftは9月24日(米国時間)、同社のWindowsデバイスに関する最新のデータを公開するページを更新し、現在世界で稼働するWindows 10デバイスの数が9億(900million)を突破したことを報告した。
> 例えばStatCounterの2019年8月時点でのデータを見ると、ほぼ正比例に近い形でシェアが上昇している。現在はWindows 10が約60%、Windows 7が31%の水準だが、
>
https://www.itmedia.co.jp/pcuser/articles/1909/30/news054.html

> マイクロソフトは、SharePointには20万の組織に1.9億人のユーザーがいると述べている[8]。
>
https://ja.wikipedia.org/wiki/Microsoft_SharePoint

シェア60%で9億台だから、Windows全部は13.5億台程度か?
それで1.9億なら、1/7の使用率になる。
見る限り共有ファイルシステムで必要な機能を全部入れてて、ついでに履歴も取れるようになってる。
共有ファイルでやる部署には必要なソフトで、また、これで十分だろう。
ただ思ったより使用率が低いのは、何か他に原因がある気はするが。
(有料だって事か?まあこれも十分な理由にはなるが)
>
https://support.microsoft.com/ja-jp/office/sharepoint-%E3%81%A7%E4%BB%A5%E5%89%8D%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E9%A0%85%E7%9B%AE%E3%81%BE%E3%81%9F%E3%81%AF%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E5%BE%A9%E5%85%83%E3%81%99%E3%82%8B-f66dbda0-81f4-4d1e-b08c-793265c58934

これも復元するときはGitと同じく「ツール上で上書き」なのが気持ち悪い。
普通につまんで取りだして、確認したあとに「手動で上書き」したい。
大体は古いバージョンなんて見るだけで十分なので、一々「上書き」しないと確認すら出来ないのがとにかく気持ち悪い。
(つかこれどこから来た文化?バージョンが古いのに差し替わっただけかはファイルのhash取れば分かるのだからそうしろよと)
No.21
個人的にはもうファイルシステムも上書きする必要なく、SSDのウェアレベリングと同様、常に新規でいいと思ってる。
ハードリンクがそうだが、あれは使いやすいとは言えないので、
各ファイル/ディレクトリに履歴が付いてて、必要なら引っ張り出せるようにして欲しいし、それだけで十分だ。
既に指摘されたように(Git19の73)、現Windowsもファイル単位ではこの機能を持ってはいるが、
勝手なときに記録され、勝手に間引かれ、勝手に停止されるのでは使えない。
保存時全部の履歴が保持されてる必要があって、
ただしどうでもいい(=メッセージが無く、かつ、バージョンも更新されてない)のは間引かれるべき、というわけ。
だからNTFSにこの機能が標準的に付けられたら、WitBucketの出番は無いね。
(Windowsがこの機能をハードリンクで実現して、勝手に管理してくれるのが一番いい。
要は上書きされてしまった昔のファイルを引っ張り出せれば良いだけだから。
どれなのかを探すのはユーザ責任でいい。日付で探しきれる自信がなければメッセージそれなりに残せ、で十分)
No.23
>>22

> Basic:650円/人月
家庭用には無しか。
地味に家庭用に履歴機能だけ付けておいて慣らして、
ファイル共有機能(家庭では不要)をBusinessで、として欲しいが。
> バイナリの管理が上手にできた方がいい。
それがどこまで出来れば「上手い」と言えるのか知らないが、多分、
・diffを表示出来るか
・圧縮出来るか
だと思ってる。
そしてSVNにはExcelファイルの差分を見るプラグイン?があるらしいと聞いてググったら、以下なのだが
> Officeドキュメントの内容比較はTortoiseSVN/TortoiseGitで瞬殺
> ところでTortoiseSVN/TortoiseGitでOffice文書の差分を見ようとするとどう表示されるか、お気付きでしょうか。
> バイナリ差分が表示されたりしません。
> Officeがセットアップされている環境ではOfficeを使って差分表示してくれます。
> しかも、Excelブックについても自力で差分表示を生成までして!
>
https://qiita.com/yuba/items/771e59b6bf1b0908e500

これだとtortoiseの機能であってGitでも出来るらしい。
そもそもOffice側にプラグインがあれば出来る、ということのようだが。
No.24
ソフトウェアの構成としては、差分表示は各ソフトに任せるべきであって、
履歴ツールの領分は各ファイルを用意するところまでだ。
tortoiseはExcelに足りなかったから補ったようで、これは確かに凄いが、個人レベルでの開発でこれは無理。
バイナリ圧縮もほぼ無理。そもそもフォーマットが公開されてないし、
単に圧縮したいだけなら圧縮DISKにセーブしろ、で終わる。
バイナリも履歴方向に対してならかなり圧縮出来るのだろうけど、それは別開発だよ。
上手く出来たら、「バイナリ用高圧縮履歴保持バケツ」として差別化は出来るのだろうけど、
diffのアルゴリズムは地味に難しいので、俺ではなくて数学屋がやるべき課題だ。
まあどちらも(diffも圧縮も)出来ないのであればrsnapshot(Git19の222=rsync+ハードリンク)と変わらんといえばそうだが。
ググるとSVNではxdeltaを使ってると出て、1997製らしいので、
>
https://yanor.net/wiki/?Subversion/%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E5%B7%AE%E5%88%86%E4%BF%9D%E5%AD%98%E6%A9%9F%E8%83%BD

>
https://ja.wikipedia.org/wiki/Xdelta

むしろこれをGitに組み込めよ、ということだと思うが。(既にそうなってる?)
xdeltaはAPL2らしいので、Gitには無理なのか?よく分からん。
とりあえずWitBucketはxdelta呼べるようにしろ、というのなら多分出来るが。
てかWindows用バイナリが無いんだがこれ。exeのリンクは全部GitHubに飛ばされてしまう。
>
http://xdelta.org/
No.25
長文君スレ立て記念
No.26
こういうやつら共通の特徴だけど、順番が逆でモノもないうちから講釈垂れるからアホだと思われるんだよw
まず動くもん作って手に取れるようにしてから「こういうもん作ったんだけど」ならスレ立ててもまともに取り合ってもらえる
この手の開発者ごっこ系のやつがまともなもん作るとこを見たことがない
No.27
PgitUp
No.29
>>28

ム板のレベルの低下を感じさせるスレだったわw
本人なんてどうでもいい、ここは言語自体を評価するスレだって言ってるやつが言語仕様に全く触れてないとか
No.30
>>26

どうなるんだろうね
みんなが欲しがってるのはgitじゃなくてこういうのだと法螺を吹きまくったから
何かしらでっち上げてもそれがgitよりもよく使われるものにならなければ意味がないし
git開発陣の技量や開発方法にもケチをつけまくったから、仕様はWitBucket(仮称)の
ほうがgitより良いのに俺(長文君)の技量が足りないからこの程度の出来になってしまった
と言って済ませることもできない
No.31
どうにもこうにもならんだろ
> ・(広告付き無料アプリ)(101)
って書いてる時点で勝手にやってろってなるわ
No.32
要するにバージョニングファイルシステムの話? VCSのラッパーで??
頭だいじょうぶかって思うが、でもこういうのって世界各地にいるんだろうなぁ
永久機関を発明したとか相対性理論の誤りを見つけた的な病人だかなんだかよく分かんないやつ
No.33
>>1

まともにプログラム組んだことないなおまえ
"Done is better than perfect"
仕様なんか後からいくらでも追加できるのだから先に基本になる部分を作ることが大事
始める前に仕様や名前募集するためのスレ立てるような奴は何も完成させられない
No.34
>>7

そのMatzと言うのはそれまであった言語の仕様や処理系の開発者にケチを
つけまくるという、長文君みたいなことをしたのかな
さっさとやれと長文君が言われるのは長文君がこれまでしてきたことの報いだろ
No.35
ここで一句
長文くん
 プログラミングは
  短文くん
No.36
そもそも名前にこだわる奴がこんな所で他人に聞いてどうするw
No.37
>>32

永久機関が無いことは理解出来るけど
相対性理論も量子力学もどちらも今の人類の到達しうる程良い近似でしかないので
後者2件は将来描き変わる可能性大有りだと思います
No.38
>>34

I hate C++. が口癖だったか
うby は perl の悪いところを真似しちゃったのが未だに負の遺産を引きずってる印象
No.39
>>37

それは関係ない
「将来描き変わ」ったとしても「相対性理論の誤りを見つけた的な病人」が
正しかったことにはならないし
No.40
>>37

永久機関がないのも現在の人類がたどり着いた近似なだけかもしれないぞ。どうやって区別した?
No.41
もう逃げたのか 今度からブログなりSNSなりでやれよな
No.42
>>22

比較ツールはwinmergeで十分だ。Excelも比較出来る。
> GUIな CVS, Subversionクライアントのお供にでもどうぞ。
>
https://winmergejp.bitbucket.io/

ただし、winmergeは現在の2つのファイル/ディレクトリを比較するように出来てるから、
SharePointやGitのような「上書き」ではなく、過去バージョンを取り出して「コピー」しないと比較出来ない。
Gitのお供に、と書いてない理由はこれだろうか?Gitは変なところでモノリシック文化になってる。
ただ、Gitなら作業はローカルで行うので100歩譲ってまだ許せるが、SharePointの「上書き」仕様は意味不明すぎる。
履歴確認は大半が確認したいだけであり、確認し終えたらそのまま捨てて終わる。
共有ファイル(=ライブのマスタデータ)を「上書き」しないと履歴を取り出せないSharePointの仕様だと、
事実上、間違って消した(或いは上書きした)ファイルの復活程度にしか使えない。
実際、共有ファイルでの履歴確認なんてその程度ではあるが、この点でSharePointでソースコードを管理するのは無理だ。
逆に言えば、SharePointはこの点を修正すれば簡易VCSとして使えると思う。
hotfixを行うには過去点に対して成長点(branch)を用意する必要があるが、これも
develop/main.c
Version4.0/main.c
Version3.0/main.c
とドベタに並べてしまえばbranchにはなる。
(こう出来るように、VersionXXXを新規ディレクトリに展開する機能が必要、ということ。
そもそもエクスプローラ的にドラッグアンドドロップでコピーがベストだが、
それが出来ないのはwindowsが正格評価で組まれてるからだろうか?
いずれにしてもelectronでもこの点は回避するのは難しそうだが《onbeforedropイベントが必要だが、無い》)
No.43
winmerge本家と日本語版があるのをご存知ないらしい
No.44
SharePointのためにMSSQL入れるとか本末転倒な希ガス
No.45
バカスレ晒し上げ
こんな奴の作ったものなんか誰が欲しがるんだ」
No.46
作ってたら、新しい事を思いつくかもしれん。
45 みたいに、何もしないで否定するだけの人って恥ずかしい。
No.47
>>45

ですよねー
No.48
>何もしないで否定するだけの人
長文君だな
No.49
>>46

× 作ってたら
○ 考えてたら
な。作ること自体は難しくないんだよ。
つかね、作ることが問題なのは初心者であって、中級以上なら欲しい物はなんでも作れるものなんだよ。
(技術的には。問題はやる気と時間、なので金で買える)
多分10,000時間超えてる連中はほぼ全員この程度にはなってる。
社畜歴換算なら5年程度で、実際その頃にはその部署で要求されることは大概出来るようになるのと同じ。
若いんだろうけど、お前らの視点は、作ることが最大の障壁=初心者レベルなんだよ。
例えば、文字を書ければ小説家になれる!絵を描ければ漫画家になれる!と思ってるのと同じだ。
お前らだって字も文も書けるわけだが、いきなりラノベ書いても無理だとは分かるだろ。
まずプロットを練らないといけないし、
それ以前に小説/ラノベ/漫画をそれなりに読み込んで作戦を練らないと話にならない。
勿論例のジャンプの王道は王道だってのも理解できないといけない。
あんま界隈詳しくないけど、「幼女戦記」は「こんなん書こうと思うんですけど、需要ありますかね?」って最初に聞いてきたらしいぜ。
自分が使うのなら勝手に作ればいいけど、商用を目指すのなら、ある程度万人受けするように作るのもまた重要なんだよ。
そもそも最発明したところで需要無いしね。
No.50
だから最低限、WitBucketを使うメリットがスパッと分かる必要があって、これには需要が重要なので、
> バイナリの管理が上手にできた方がいい。 (
>>22
)
みたいな仕様要求が今ここで話すべき事なんだよ。
(ただし出来る出来ないは別で、実際、Gitをバックエンドにする限りGitと同程度にしかならない。
勿論SVNを使えばSVNと同程度にはなるが、これらならGit/SVNをそのまま使えば済むので、
何かしら訴求力がないと話にならない。とはいえアルゴリズム系は俺には厳しい。
GUIだけで差別化も勿論有りだが、それなら他に同じGUIが無いことは最低限確認しないと駄目だろ、ということ)
ただ以下とか読んでると、俺が(或いはみんなが)欲しいのはもしかしてSVNのローカル版か?とも思えてきた。
>
http://wastedpotential.com/version-control-throwdown-git-vs-svn/

SVNもまあぼちぼち確認してみるよ。
つかtortoiseってなんぞ?と思ったが、SVNがturtleなのか。
No.51
精神論を語るあたり本当に社会経験なさそう
あるいはドロップアウトしたか
No.52
頭で考えるだけで、できると思う奴もおかしい。
そんなのだったら、映画撮る前から傑作な事が分かってしまうはずだけど、大抵はそんな事ない。
音楽その他も同様。
形になり始めてから気が付くこともある。
No.53
>>49-50

さっさとやれと長文君が言われるのは長文君がこれまでしてきたことの報い
ああいうことをやってなければ「考える」のに何年、何十年かけようと
挫折して何も作れずに終わろうと何も言われずにすんだのに
No.54
>>52

それはそうだが、事前検討を放棄しては駄目だろ。
そして音楽や映画の連中も当たり前だが相当に検討済みで、それでもスベってるだけだ。
そりゃ中には己の世界観を表現出来れば良いのだ!みたいな芸術家タイプで大成する奴も居るだろうが、
少なくと俺達はアーティストではなくエンジニアなのだし。
No.55
gitスレでは邪魔だったけどここで勝手にやるのを邪魔する必要はないじゃん。
生暖かく見守ってやれよ。
No.56
誰も邪魔してないけどな
No.57
ほんでどこまでできたの?
No.58
>>56

俺は邪魔してるよ
No.59
というかね、お前ら根本的に勘違いしてるが、Gitが凄いのは仕様であって、実装ではないんだよ。
実際、Gitの最発明は、gitoxide(Rust実装/Gitスレ19の48)でもSaplingでも出来てるだろ。
Git自体に実装上難しい部分はないから、実装出来ないのなら単に技術力が足りてないだけであって、
これをまるで理解出来ないお前らは、本当に全くプログラミング出来ないことをお前ら自身が証明してるだけなんだよ。
その他の部分もだいぶ酷いが、このスレではGit屋をフォローする意味はないので放置だが、
5chの場合は書き込みが永久に残り、読み返されることは認識しておいた方がいい。
お前ら個人と紐付けされることはないだろうが、Git屋ってこの程度なのか、というのは未来永劫記録として残る。
No.60
>>59

Gitに文句つけて該当スレ荒らしてたのはこのスレ立てた人だと思ってたが
No.61
>>59

>5chの場合は書き込みが永久に残り、読み返されることは認識しておいた方がいい。
長文君がな
>>49

>自分が使うのなら勝手に作ればいいけど、商用を目指すのなら、
>ある程度万人受けするように作るのもまた重要なんだよ。
>そもそも最発明したところで需要無いしね。
多くの人が欲しがっているのはGitではなくて「バケツ」というのが長文君の主張
「バケツ」は万人受けするから、作られればみんなそっちに乗り換えるということだろ
多くの人が望んでいるのが「バケツ」だとしたら誰もそれを作らないのはなぜと問われて
俺が作ると言うしかなくなったけど、やりたくないしできないから作らずに済ませられる方法を
探し続けているのが長文君
No.62
既に出来たものを見てあれぐらいは俺にも簡単だ
とかほざくのは初心者あるある過ぎて草も生えんわ
No.63
>>61

> 長文君がな
そうだな。お前らGit屋がここまでの粘着体質なのは想定外だったので、
俺自身も匿名化、つまり作ったとしてもここでは発表しないとかも考えないといけないとは思ってるよ。
ただまあそれはさておき、俺に粘着したところでGitのコードと開発体制が(通常から見て)糞なのは変わらないし、
メモリリークがあのコードで直りきることも無いがな。
しかし最終的な目標は「長期的保守」であり、コードや開発体制は手段に過ぎないのも事実だが。
> 多くの人が望んでいるのが「バケツ」だとしたら誰もそれを作らないのはなぜと問われて
> 俺が作ると言うしかなくなったけど、
これには答えてないだろ。つかお前が勝手に捏造してるだけだな。
こういうやり方をする韓国人な奴に対しては、一々修正すると無限修正を余儀なくされるので、
無視がセオリーだが、今回だけ答えておくと、
> フォーカスグループ(ある集団に商品についての考えを質問するマーケティング手法)によって製品をデザインするのはとても難しい。
> 多くの場合、人は形にして見せてもらうまで、自分は何が欲しいのかわからないものだ。
> スティーブ・ジョブズ
の通り、現物がないと人は「ああ、俺は実はこれが欲しかったんだ」とは分からないものなんだよ。
だから最初の製品を作るのは難しい。
そして俺が今やってるのは、「本当にこれが欲しいのか?」を詰める作業であって、お前らの想定よりも前の工程だ。
No.64
Gitが難しいとは言われてる。(お前らはこれすら否定するようだが)
だから「簡単なGit」には需要があって、それが「これで十分じゃん」と思えるものなら大半は乗り換えるだろう。
多少簡単なくらいで、(信頼性や実績や3rdパーティツールを鑑みて)「乗り換えるまでもない」と思うのなら、無視されるだろう。
Saplingは俺と同様、Gitの「分かりにくさ」はIndexにあると見て、これを廃止した。
あとおそらくMVCを導入して、rebaseを廃止するつもりだろう。これも俺と同じ方向だ。
(Git19スレの331。なお既に何度も言ってるがまるで通じてないが、しつこく言っておくと、
これはrebaseしなくてもrebaseしたのと同じ見た目を得られるということ)
なら単純には俺はSaplingにcontributeすべき、という話になるし、それ以前に
(哲学が同じ)Saplingが「バケツ」的UIを既に実装してる可能性もかなりある。
そして俺が今やってるのは、俺が欲しい「バケツ」って、実際どういう「バケツ」なの?を詰める作業だ。
(ちなみに俺が欲しいcommit/rebase履歴はMVC分離の先にあるから、Saplingとは相性がいい)
No.65
商用で作るのなら宣伝に当たるこのスレがアウトの気がするw
運用どころか具体的な始め方も考えてなくて
>>32
が正解なのかな
どちらにせよ完成するまでGitスレには戻るなよ
アイデアは間違ってなかったが邪魔されて作れなかったとかの言い訳は無しなw
No.66
うわ、本人降臨してたのかよ
>>64

こんなところに書き込む暇があるならせっせとコード書けw
No.67
>>65

> 商用で作るのなら宣伝に当たるこのスレがアウトの気がするw
そう思うのなら通報どうぞ。お前らの望みも叶うだろうし。
No.68
>>65

心配しなくてもどう見ても売り物にならんだろw
No.69
>>32

>永久機関を発明したとか相対性理論の誤りを見つけた的な病人
こういう人たちの特徴として挙げられるのに自分を偉い人たちと重ね合わせるというのがある
〇〇はこうした(こう言った) 私も同じようにしているのだ
〇〇は正しかっただろう 私が正しいこともいずれ分かる
といったぐあい
〇〇と自分の違いについては考えない
No.70
>>63

ジョブズが言ってるのは消費者の話だろ
作ることができない人がこういうのをつくったらどうだろうと考えないのは当然
何か思いついたとしてもアイデアは実現されることなく消えていく
一方で「バケツ」は作ることができる人の話だ
gitは複雑過ぎると思っている人が圧倒的多数というのが長文君の主張だが
その人たちは何故誰も「バケツ」のようなものを作ろうとしないのかという話
No.71
>>69

統合失調症患者が自分はキリストだって言う理屈だな
キリスト自称する人には奇跡の一つでも起こせ、
>>1
にはプロトタイプの一つでも公開しろ、まともに話を聞くのはその後ってことか
No.72
>>64

「俺が欲しかったのはsaplingだったんだ!哲学も同じだ!」と言い張って済ませようということかな
>>61
>やりたくないしできないから作らずに済ませられる方法を探し続けているのが長文君
No.73
>>66

長文くん専用のスレだからどちらかといえば部外者はお前だぞ
No.74
どういう場所だと思ってんのか知らねーけど5chのスレで誰が部外者だのなんだのねーんだよ
個人アカウントのブログなりSNS上でやってんならまだしも、いくらか脳ミソが欠損でもしてんのかねw
No.75
>>70

お前は本当にいつも根本的に間違ってるよな。
原因は心の傲慢さだよ。どこかで常に他人を見下してるから学べない。
ジョブスは、「消費者が本当に求めている物は、Apple内での『フォーカスグループ』議論では出てこない」と言ってるんだよ。
作れる作れない関係なく、そもそもイメージ出来ない奴でほぼ全員なんだ。
ただ、目の前に差し出されたら、「ああ、これは良いね!僕はこれが欲しい!」とは誰でも言えるわけ。
有名なのはスレート端末で、iPhone以降は他社含めて全部そうなった。だからこの判断が正しかったのは事実だ。
しかし同時期にgoogleその他はベリー端末を計画中で、iPhoneのデザイン案を見て急遽切り替えた(とジョブスは言っている)
のでジョブスはパクッただろ!とブチ切れてた件だ。
今ならイーロンマスクが新しいツイッターのサービスを出してくるかもしれないが、
今ツイッターを使ってる奴は、仮にその新しいサービスの廃人になって、それ以降は無くては生きていけないほど依存するとしても、
今現在はそれが無くても何ら問題を感じられないものなんだよ。
今ツイッター廃人の人も、ツイッター以前には普通に生きてただろ。Line廃人もスマホ廃人も同様だ。
「Gitが無い時代、どうやって開発してたか分からない」というGit廃人みたいな連中も偶にいるが、
そいつらも、Gitが無い時代にプログラミングしてたら、Gitを欲しいとも想像出来ないものなんだよ。
No.76
だからSaplingが出てきたのは相当意味があって、
少なくとも現物を見れば「僕はこれが欲しかった」かどうかは誰でも言えるので、結果は出る。
見る限り俺の場合はGitよりSaplingだろう。
Indexを邪魔だと思ってる連中も同様だとは思うが、commit -a で済むのでわざわざ移行するほどでもないのも事実だ。
だからSapling自体は極めて中途半端な仕様で、この点をGitスレ19の324で指摘されてる。
それに対する君の回答が325で、相変わらずトンチンカンなことを言ってる。
俺の回答は331で、324はMVCを理解してる奴なら普通に感じる疑問点であり、それは現実的に妥協したのだ、という解釈だ。
実際の所、現仕様のSaplingでは移行する意味がないのも事実だが、
次仕様のSaplingはGitに足りない部分を実装するはずであり、これを使いたい奴は移行を検討するだろう。
(というほど移行の障害もないが)
Linusは自分が使う用にGitを作った。これは正しいし、全く問題ない。
問題は、それがLinuxカーネルの様な全世界規模の同時開発用であって、
OSSにはそれなりにフィットするが、
プロプライエタリには全くフィットしないことだよ。
だから自分でプロプライエタリのコードを書きまくってるmetaからはGit改としてSaplingが出てきた、というわけ。
Git陣営は、自分でコードを書く気は全くなくて、誰かが書いてくれたコードをmerge出来ればいいようだ。
これが実際バザールとして機能するにしても、
誰かがそのコードを書かなければ始まらず、そのサポートがGitにはないから、
metaのようなコードを書く側には不満だったんだろうよ。
(とはいえ普通は我慢して使うが、metaがわざわざ作り直したのは、rebaseに関しての論争に決着を付けたかったんだろう)
No.77
>>75

>>63
>一々修正すると無限修正を余儀なくされるので、無視がセオリー
と言ってたのに無視できないのが長文君
無視できないなら言わなければいいのに
>「消費者が本当に求めている物は、Apple内での『フォーカスグループ』議論では出てこない」
作るのは大変だし自分で作れるわけでもないからそういう発想は出ないんだろ
長文君の主張によると、多くの人はgitではなく「バケツ」を欲しがっているわけだ
そして「バケツ」を作るのは難しくないということだった
であれば実際に「バケツ」を作ってみる人たちが現れても良さそうなものなのに現れない
「バケツ」を欲しがっている人たちは(ほとんど)いない
「バケツ」を欲しがるのは無能ばかりだから作れない
の どちらか、あるいは両方だと思うがな
No.78
>>74

お前らがgitのスレでは迷惑だからスレッド作ってそこでやりなって言ったんだろうがw
No.79
>>77

そうだね。
では今後は全て無視するから、コテ付けてくれ。
よろしく頼むわ。
マジな話、お前はズレ過ぎてて、話す価値がない。
ただな、いずれにしても、ここで合意を取る必要はないんだ。
お前はそう思う、俺はそうは思わない、これで終わりだ。
俺は既に何度も言ってるが、売れると判断すれば作るし、売れそうにもなければ作らない。
作るのを手伝えとも言ってない。だからお前がわざわざ粘着する意味も分からない。
お前らは誰かが勝手に作るかもしれないツールを、使えそうなら使えばいいし、ゴミだと思えば使わなければいいだけ。
Saplingや他ツールに対しても一般的にはこのスタンスが標準だと思うがな。
お前がそこまで粘着する意味はなんなんだ?
お前がGitの開発者でもなければ、自身の分身と思えるほどcontributeしてきているわけでもあるまい。
そして再度言うが、俺に粘着してもGit開発陣は糞のままだし、コードも改善されることはない。
そういうことを言うな!と切れるのなら、まずはGit開発にregressionテストを導入すべきであって、
俺に粘着するのは明らかに方向性を間違ってるだろ。
あとやっぱりズレてるのは、「Gitを作るのは難しい」とお前が思ってることだ。
Gitを『初めて』作るのは難しいんだよ。これは既に言ったように思いつけないから。
Gitを『再開発』するのは簡単なんだよ。これは何も難しい構造がないから。
お前はこの後者も難しいと思ってるからズレる。
それはお前が至らないだけであって、多分そこら辺の職業プログラマならGitを『再開発』するのは余裕だよ。
(だから既にgitoxideやSaplingが出てきてる、とは59で言ったとおり。探せば他にもあるだろうよ)
No.80
あともしかすると、Gitみたいな「コミュニティ至上主義」(=人数こそ力の源泉)においては、
もしかすると他類似ツールで人数が減ること自体が死活問題であり、(=他ツールを選べること自体が悪)
禁忌だからここまで攻撃的粘着をするか?とも思うが、これ当たってるか?
なお俺みたいな「コード至上主義」なら類似ツールは無限に出てきてもウェルカムで、(=選べること自体が正義)
自分で選ぶのが面倒だから皆さんが味見した後のレビューでも見てよさげな奴を選ぶか、程度だが。
(なので皆さん是非Saplingも味見してブログなり書いてください)
LinusがSubversionをボロクソに言ってるのも正直意味が分からないんだよね。
糞だと思うのなら参加しなければいいし、使わなければいいだけだろ、って話で。
(だからこの辺の価値観/距離感が俺とは違うのかなと。まあ俺はネットの匿名世界に毒されてる側ではあるけど)
No.81
>>79

「ズレ過ぎてて、話す価値がない」と思うのを無視すればいいだけだからコテを付ける必要はないな
長々と書いてるけど
>>77

>「バケツ」を欲しがっている人たちは(ほとんど)いない
>「バケツ」を欲しがるのは無能ばかりだから作れない
>の どちらか、あるいは両方だと思うがな
は否定できないということだな
>>80

>糞だと思うのなら参加しなければいいし、使わなければいいだけだろ
と、gitは仕様も開発陣も糞だと暴れていた長文君は宣った
No.82
>>81

> は否定できないということだな
これが典型的な攻撃方法なんだよ。
デタラメに言って、何かしら相手から情報を引き出すやり方だ。
これに対する適切な対処方法は、ランダムに答えたり無視したりすることなんだよ。
常に答える、或いは常に無視する、では情報を与えてしまうので。
(とはいえ世界では黙ってたら認めたことになる、だから、あいつらももうちょっと成長して欲しいが。
マジな話、一々訂正しててもキリがないし、そもそも不在だったりもするしで)
ただな、そもそも現時点でこういう攻撃を受ける意味が分からない。
お前はどの方向を向いた正義マンなんだ?
ちなみに俺は、リアルでは絶対に会えない連中とも話が出来るのがネットの醍醐味だと思ってるから、
価値観が異なる奴から意見を聞くのは割と楽しい。
ただお前は「技術的には」本当に稚拙だから、技術的な話をする意味はない。
でもどういう価値観からそういう行動になるのかは聞きたい。
普通はな、追い出した先まで粘着はしないんだよ。それでは追い出した意味がないから。
だからこのスレまで粘着してきてるGitスレの連中は全員キチガイと相場は決まってて、実際そうだろ。
ただお前はキチガイの割には話せるタイプなので、どこに立ったらそうなるのか?を聞きたい。
ちなみにな、
> は否定できないということだな
否定出来ない、ではなく、否定する意味がないんだよ。
そもそもどっちが正しいかはforkで決めるのが正しい。
ここで議論して決着付けるものではないし、付くものでもないんだ。
> と、gitは仕様も開発陣も糞だと暴れていた長文君は宣った
GitスレはGit開発に参加してることにはならないだろ。お前まさかここを勘違いしてる?
No.83
で?どこまでできたの?
No.84
>>82

長文君が言ってることをまとめると
>「バケツ」を欲しがっている人たちは(ほとんど)いない
>「バケツ」を欲しがるのは無能ばかりだから作れない
という結論になると言ってるだけ
>マジな話、お前はズレ過ぎてて、話す価値がない
>ただお前はキチガイの割には話せるタイプ
どっちなんだ
>糞だと思うのなら(略)使わなければいいだけ
と、gitは仕様も開発陣も糞だと暴れていた長文君は宣った
No.85
Gitスレではウザかったが、専用スレなら好きにすれば良い。
粘着して批判してる奴らは無視でいいだろ。
目指してるとこは面白いと思うけど、俺にはあまり役に立つケースが思いつかない。
ただできてみれば思いの外便利なものかもしれないので、どんどん具体的にしていってくれ。
No.86
あともう分離したんだし、不要なGit批判は荒れるだけなんで止めてくれ。
説明のために対比するのは構わないけど。
No.87
>>84

> どっちなんだ
お前と技術的な話をする意味はないが、
Git屋の価値観には興味あるので、これについて何か語って欲しい。
> 糞だと思うのなら(略)使わなければいいだけ
ああ、これに関しては既定路線だと言ったろ。
今回はGitを使うことも目的だから、糞であろうがなんであろうが使うんだよ。
ただその最中でバグに当たって、
報告したらいろいろとんでもない糞だったというのが判明しただけ。
> という結論になると言ってるだけ
君がそう思ってるのならそれでいいし、あまり訂正する意味もないが、俺は以下になる。
・自分達には「バケツ」の方が適してると認識出る奴が(ほとんど)居ない
・だから「バケツ」を作ろうという発想にもならないが、「バケツ」自体は作ろうと思えば誰でも作れる
ただ何度も言ってるが、これは合意を取るものではないんだ。
だからお互い言いっぱなしでいいんだよ。
スレート端末だって、技術的にはむしろ簡単なはずなんだよ。だからgoogleも急遽変更して追従出来た。
ただ最初に、スレート端末で全て行けるんだ!と見極めるのが難しい。だから作ろうとも思えなかったのがgoogle。
同様に、「実はバケツで十分なんじゃね?」って見極めるのが難しいんだよ。
そしてこのスレでは、その「バケツ」に必要十分な機能とは何か?をまず議論したい訳よ。
つまり、仕様だが。
No.88
>>85

> 俺にはあまり役に立つケースが思いつかない
元々Gitを使えてる連中向けではないからな。基本的に、
・Git?何それ美味しいの
な連中向けであり、コンセプトは、
・「バケツ」の分際で50-100時間勉強しろとかおこがましい。
・一度突っ込んだら、明示的に消してない限り、頑張れば探し出せる。
だからね。
対象は、「Gitなんて勉強する気もありません。が、ゴミ箱ですか?そりゃ使えますよ」など素人向けだ。
No.89
なおSubversion、今読んでるが、
> Subversionはハードリンクとして知られている方法とよく似た方法を使って、単にプロジェクトをコピーすることでブランチとタグを作ります。
> そのため ブランチ、タグの作成は非常に短い、一定の時間しかかかりません。
>
http://jtdan.com/vcs/svn/svn-book/svn.intro.features.html

ブランチ作成は対策出来てるのはいいが、
> /tmp/myproject/branches/
> /tmp/myproject/tags/
> /tmp/myproject/trunk/
>
http://jtdan.com/vcs/svn/svn-book/svn.intro.quickstart.html

この管理用ディレクトリがユーザーディレクトリと並ぶ構造はよろしくないのと
(Subversionをよく知っていること=知識的に密結合が要求される)
> 混合リビジョンは正常な状態です
>
http://jtdan.com/vcs/svn/svn-book/svn.basic.in-action.html

これは分かりにくいね。Gitみたいに完全に分離してる方が分かりやすい。
(こんな説明が必要な時点でアーキが糞。だってGitの構造ならこの説明がそもそも不要だし)
まあ俺が作ろうとしてるのはVCSではなくて「消えないゴミ箱」なんだけどさ。
No.90
>>87

言いっぱなしでいいならこれで終わりでいいだろ
>「バケツ」を欲しがっている人たちは(ほとんど)いない
>「バケツ」を欲しがるのは無能ばかりだから作れない
違うということなら実際に「バケツ」を作って示せばいいんだから
>自分達には「バケツ」の方が適してると認識出る奴が(ほとんど)居ない
「バケツ」の方が適しているのは、gitに不満を持っていてもっと単純なもので
いいと思っているのに「簡単に作れるツール」を試しに作ってみることすら
できない奴ばかりということだな
No.91
結局いまどの段階で何を考えてるんですか
クラウドストレージの履歴と同じものならすぐ作ればいいでしょ
No.92
長文読む気しないけどそんなにディレクトリが好きならGit FUSEでも使えば満足しそう
No.93
>>90

> 「簡単に作れるツール」を試しに作ってみることすら
> できない奴ばかりということだな
これも違うんだな。
というかマジでお前、基本的に人を見下してるからこんな発想になるんだよ。
何故お前が『実装が』難しいことにしたいのかはさっぱり分からないが、
Gitの実装は簡単な類で、POSIX先生が学生にやらせるのも分かるよ。
スクリプト初心者にはかなり厳しいが、題材としては悪くない。
> gitに不満を持っていて
ここが違う。明示的な不満を感じられてない。
携帯がなかった頃も、ネットがなかった頃も、スマホがなかった頃も、みんな普通に生活してた。
Gitが無かった頃も、みんな普通にプログラミングしてた。
そして今、Gitがあって便利なわけだが、なかなか勉強が必要で、でもそんなもんだと思ってる。
『でもんそんなもんだ』がミソだ。
これは、今丁度W杯で本田の解説が話題になってるのが良い例になる。
これに対して5chでも色々言われてるが、(以下覚えだが)
> 解説の新しい境地を切り開いたのが最大の功績だ。
> これまで解説は10点満点で5点か、みたいな感じだったが、
> 実は100点満点で、これまでの解説陣が全員ゴミだとはっきり分かってしまった。
> 今後は解説に対しての目が厳しくなるだろう。
みたいな意見をしてた奴が居たが、全くこの通りで、
本田の解説を聞くまではサッカーの解説なんてこんなもんだ、とみんな思ってたんだよ。
それが見事に覆された。だから話題になってる。
でも、本田以前に、そのことに気づいていた奴は皆無なんだよ。再度言うが、みんな『そんなもんだ』と思ってた。
これをジョブスは言ってるんだよ。プロ中のプロで、毎日サッカーの試合見てて、他人の解説も聞いてる奴でも、気づけない。
同様に、Gitを毎日ゴリゴリに使ってても、Gitの問題には気づけないものなんだよ。
No.94
いやだからその100点を見せてくれよ
No.95
定期でこんなスレ立つが何か作るってのはパパとママに言えよスレ立てて公表することじゃない
その上売れそうにないと判断した場合はそもそも作らないって正気かよ
実績が何もない人間の作ったものはタダでも誰も使わない
最初から作るつもりもないただのかまってちゃん全開じゃねーか
No.96
>>94

それが分からんからここで詰めようぜ、という話だ。
単純に言うと、『そんなもんだ』をぶち破る発想が必要で、それが例の
・ゴミ箱でバージョン管理する
にあるから俺は目を付けた。これに対してのスタンスは、
お前ら: ゴミ箱だと消えるから駄目だろ。馬鹿にも程がある
俺: なるほど良いアイデアだ。なら、「消えないゴミ箱」にすればいいのか?
結局のところ、最初の『発想』が出来ない理由はお前ら老害(またはゆとり害/若害)が『常識的に』潰してるだけなんだよ。
『そんなもんだ』が最初にあるから、平凡な発想しか出来ない。
そして見た目トンデモだが実は重要な発想も、自分自身で握りつぶしてきてる。それが俺に対して
> 長文君にはゴミ箱がお似合い (Git19の59)
といったお前らの実態だよ。だからお前らも十分老害/ゆとり害/若害のどれかであることは認識した方がいい。
(少なくとも目の前の新人がゴミ箱で管理してるのを見たときの対応が俺とお前らではかなり違う)
そしてお前らが俺に対して「○○も知らないのか」と言って馬鹿にしてきたそれぞれの案件が、
俺にとっては素晴らしい養分だったわけだよ。
現段階はブレインストーミングに近く、アイデアこそ重要だからね。
…なんだが、「これだよ!これが欲しかったんだよ!」になるにはあと2,3個は何かしら発想が必要で、
・トンデモな発想を募集中(例:ゴミ箱)
というわけだ。ゴミ箱みたいに「常識的にそれはないが、言われてみると確かに…」な案件がベストだ。
俺はとりあえず正攻法でSVNのbookを読んでる。(SVNのアイデアを観察中)
No.97
>>96

仕事じゃないんだから単に消えないゴミ箱を作れば良いんじゃないですか
No.98
>>93

俺がgitに不満を持ってるのだから他の人も不満を持ってるはずだと
長文君が思い込んでるだけだな
No.99
>>69

そういう人たちの特徴として挙げられるものに「迫害されてると考える」というのもあった
長文君は「さっさとやれよ」を迫害と思ってるらしい
No.100
>>97

逆だ。仕事にしようとしてるんだよ。最初から商用で広告付き、と言ってるだろ。
というかね、折角環境が整備された今、プログラマはもっと自由に生きるべきだろ。
本当に必要なツールを作ったら、それなりに売れて生計も立つ、という循環を目指すべきだ。
(これが本来のSDGだよ。今SDG言ってる奴はパヨってて、逆にSDG言ってる奴=ヤバイ奴になっちゃってるけど)
OSSがどうやって資金を調達しているのかいまだによく分からないが、
結局の所、大半はスポンサードなのか?ならそれは独立してるとは言えないだろ。
それなら批判はあるがBraveの方がまだ正道のように見える。(広い意味では広告アプリだが)
本来、個人で作れる程度のツール群は、
・こんなのが欲しい、というユーザ側と
・広告アプリでよければ作ってやるよ、というプログラマ側の
交流の場があれば普通に成立するはずだろ。これを目指してる。
No.101
自己紹介板でもないのに自己紹介のスレ立てて「製作を検討中です」って書けば「さっさとやれよ」って言われ続けるのは当たり前だな
もしかして自分で自分を追い込んでいるのに気づいてないアホなのか
No.102
>>100

「こんなのが欲しい、という」人は自分で作る
「この板はプログラムを作る人のための板です。」
作る作る詐欺の人は叩かれる
No.103
「こんなのが欲しい、というユーザ」は当面現れなさそうだし
自分で「こんなのが欲しい」と思った範囲で作ればいいじゃんよ
No.104
>>100

「バケツ」を欲しがってるのは長文君だけだから交流も何もないんだよな
長文君が実際に「バケツ」を作って公開すれば試しに使った人との交流が
始まるかもしれないけど、「さっさとやれ」と言われてもやらないし
No.105
>>100

売りたいということがわかって、まあいろいろ考えたいこともわかったけど、アップデートでなんでも対応できるのがソフトウェアのいいところでもあると思いますよ。
>>104
の言うように、なんならあなたでさえも何かを欲しがっているようには見えないから成立してないんじゃないですか
No.106
>>99

それ自体は「迫害」ではないが、お前らクズGit屋がナチュラルに「迫害」している事は事実だよ。
お前は何が「迫害」なのか理解出来ていない。
> 【コミュニティの一生】
>
> 面白い人が面白いことをする
> ↓
> 面白いから凡人が集まってくる
> ↓
> 住み着いた凡人が居場所を守るために主張し始める
> ↓
> 面白い人が見切りをつけて居なくなる
> ↓
> 残った凡人が面白くないことをする
> ↓
> 面白くないので皆居なくなる
これって、「面白い人」にとっては、常に「凡人」につきまとわれて、
結果的にいつも居場所を壊されて立ち退くのを余儀なくされる。
これは定義通りの「迫害」だよ。
つまり、ネット上では、正当な方法で耳目を集められる連中は常に迫害対象であり、
迫害してる連中は、特に面白くもない大半の凡人なんだよ。
そして今まさにお前らクズGit屋がこのスレでやってるのもこれだろ。
お前らはナチュラルに迫害してる、それはこのスレのみならずどこでも、というのを自覚した方がいい。
大体そもそも追い出した奴に付きまとうのは、マジキチでしかないだろ。一体何がやりたいんだよ?
なんでそこまで性格が歪んでしまってるのさ?それはGit文化によるものなのか?
(偶に粘着してくる奴はいるが、大体そいつらは例外的なキチガイっぷりなのでどうにもならない。
ただ、Gitスレの連中は多すぎるし、キチガイ度が足りない。
この意味では、Gitには何かキチガイ化を促進する要因があるのだろうよ)
No.107
>>106

長文君、被害妄想激しすぎ
>>63
>現物がないと人は「ああ、俺は実はこれが欲しかったんだ」とは分からないものなんだよ。
とか言ってるけど、本当にそう思ってたら実際に「バケツ」を作って見せてから意見を求めるだろ
なのに作らず、さっさとやれと言われてもやらず、御託を並べ続けるだけなのが長文君
No.108
>>105

急ぐ合理的な理由がないんだよ。
リリースしたら即爆売れするほどブルーオーシャンでもない。むしろレッドオーシャン。
なら、3ヶ月仕様を練って狙い撃ちしないと当たらない。
No.109
>>106

コミュニティの一生とかいうのも長文君には当てはまらないな
長文君が「バケツ」をつくって公開し、ユーザーが増えてコミュニティができるけど
勝手なことを言うユーザーが増えたために長文君がやる気をなくしてやめてしまった
ということなら当てはまるかもしれないけど、そうなってないし。
それに「バケツ」が有用なものなら、長文君がやめてもコミュニティの中からforkして
続ける人が現れ、そっちのコミュニティに人が移って続いていくだけだから
コミュニティの一生とかいうのを持ち出しても意味はない
No.110
>>106

> 面白い人が面白いことをする
もうここから...
No.111
長文くんの足を引っ張りたい人の意見は人間的に間違ってるな
No.112
>>111

事前検討が必要って言って何もしない本人が足引っ張ってんな
作って動かしてバグも含めてまず自分が使いたい形へ改良していかなければ他人が使いたいものはできない
早く作れって言うのが親切だよな
No.113
100レスにもなってまだ設計は一ミリも進んでないのか
No.114
何事もまずはまずは要件検討からですよ
No.115
こんなところに潜在ユーザなんていないからどっか違うところでやれば
twitterの駆け出しエンジニア()界隈とかさ
No.116
>>114

要件検討すらやってないぞ
No.117
>>106

自分が面白い人でGit屋という敵に攻撃されてると思ってるの
病気なのか子供なのか知らないけど変な妄想治るまでネットから離れた方がいい
このスレも元から板違いであなたが叩かれるだけのスレになってるからね
ただツール作るのは誰も邪魔しないから好きにしたらいいよ
No.118
ほら
飽きた
No.119
長文君が消えたのは良いこと。
現物を見せられるまで人は自分が何を欲しがってるのか分からないというのが
長文君の主張のわけで、他人に見せられるくらいの「現物」を長文君が実際に
作って公開しないと話にならない
公開して利用者の批判や要望を基に改良していくのは他の場所でやればいい
長文君にとってここは「Git屋の巣窟」だろうし
No.120
「構想練らなきゃならないから3ケ月後から本気出す」っていう人は身の程知ることから始めた方がいいわ
プログラム初心者でも「なんだ作れないのか」ってわかる
むしろ3ヶ月間本気でがんばり続けていいものに仕上げていかなきゃならんのに
No.122
本人も何がほしいかわかってないんでしょ
だからモチベーションが続かない
No.123
モチベーションって長文書き込んでるだけじゃん。辻褄合わない内容も多いし
虚言癖あって長話したがる老人のイメージ
No.124
毎日一回とは言わんが
週一で良いから進捗報告汁
その方がモチベも上がるだろ
No.125
進捗ないやつが進捗履歴管理ツールとやらを作るの?www
No.126
>>123

そんな感じだな
現物を見せられるまで人は自分が何を欲しがってるのか分からないということだったのに
さっさと「現物」を作って公開しろ、みんなが欲しがっているのがどういうものか
分からないとどうしようもないだろ、と言われると迫害されたと言い出すしな
No.127
「確実に売れそうな画期的アイデアくれ。売れそうになければ作らん」
こんな甘えたこと言ってるやつまともに相手できんやろ
そんな画期的アイデアあったらこのスレ見た別の人が先に作るわ
No.128
>>125

自分用のも作ってないらしいからな。なぜかそこだけは一貫しているのがいろんな意味でおかしい
Gitスレ見てないけど必要なツールだと思って作ろうとしたんじゃなかったのか
自分が必要とするツールならある程度使える部分まででもとりあえず作ってしまうのが普通だと思ってた
No.129
>>128

長文君は暴れたかっただけだからな
Gitは仕様も開発グループも糞だ、Gitなんか簡単に作れる、大多数の人が望んでるのは
Gitじゃなくて俺の言うバケツだとか言ってGitスレで暴れた結果
自分でバケツを作ると言うはめになった
でもそんなの作れないから作らずに済ませようとしてる
No.130
干し芋のは首輪でしたというオチ
No.131
悲報:もう12月
No.132
>作る場合は、2023年3月末リリース目標
ただし要件不足、昨日募集するも集まらず、実装のためのたたき台もいまだ無し、売れる見込みも当然無し
本人は他のバージョンツールの仕様勉強中と言った後に逃走
No.133
個人的なディレクトリを日次スナップショット100日保管で回してるけど、ここ10年くらいで過去の版見にいったことって実は1回しかない
No.134
githubでもissueにforkしてやるとか
わめいて結局何もしない荒らしは結構いる
No.135
作者さんどこー!?😭
No.136
大嫌いなgitをエンジンとして使うのはモチベーション上がらんのだろう
No.137
大嫌いなgitをエンジンとして使うからモチベーション上がらないということなら
gitをエンジンとして使わなければいいだけだよな
No.138
何も作ってないんだから作者なんていないだろ
No.139
ツール作るとスレ立てて
事前検討が必要だからと御託だけ並べ続けて
自分は迫害されてると喚いて
何も作れずに逃げ出した人のスレ
No.140
5ch 時々、規制がかかる時があるので2ヶ月くらいは待ってみるアル
No.141
長文君が5chで続ける必要はないわけで
>>119

長文君が他で続けるなら、このスレのURLを示してそこで迫害されたから
ここに来たとでも書くはずだけど、このスレのURLでググってもそれらしいのはない
No.143
完成マダー?
No.144
>>142

王道を王道と(ry
No.145
>>3

ここで名前についてグダグダやってるあたりで察した
名前にこだわるのはバカのすること
No.146
プログラムに限らず物作る前に名前にこだわってたらバカだよな
そんなものは作ってから宣伝する前に考えればいい話
No.147
分かりやすい名前付けられると想像力が広がって作るものの道が見えてこない?
先は長いから名前重要と思うけど。
まあ、後から変えればいいんだけど、大抵最初に付けた名前が一番いい。
No.148
>後から変えればいい
で終わってる話
No.149
>>147

エジソン「いちいちそんなもの考えてねーわ」
とりあえずこのスレの
>>1
にその話はあてはまらない
俺らが気付かないような素晴らしいものを作るってずっと言ってんだから作るもののコンセプトをスレ立ててから広げてたら話が違う
No.150
先に名前考えたらクラス名考えやすくてコーディングしやすい
No.151
>>150

名前ってクラス名も含めて何のためにつけるかわかってなくね?
見た人が分かりやすくするためでそうじゃなければA001、A002とかで十分
No.152
>>151

自分が書くコードは他人も見るのが前提だからそんなクラス名は論外だね
No.153
>>151

それは流石にない
ただプロジェクト名を先に決めようとしてグダグダ時間浪費するのはたしかに馬鹿
No.154
名前は重要
ただ名前の付け方の経緯なんて他人にはどうでもいい
No.155
名前が決まらなくても中身は作れるだろ
やりたいことは決まってるんだから
No.156
>>150

クラス名は役割に応じてつけるだろ。なんでプロジェクトの名前が影響するんだよ
中身がクラス1つ2つなのにクラス名にこだわったりローカル変数の名前もこだわるアホ?
中身が作りこめないプログラム初心者の発想だよそれ
No.157
たぶん全クラスの接頭詞にアプリ名をつけるタイプなんだろう
No.158
長文くんはgitの素晴らしさに今更気づいて恥ずかしさで出て来れないんだろな
No.159
>>147
とか長文くんっぽいけどなw
No.160
ベストナイン
1番 (右) イチロー
2番 (左) 張本 勲
3番 (一) 王 貞治
4番 (三) 長嶋 茂雄
5番 (二) 落合 博満
6番 (投) 大谷 翔平
7番 (捕) 野村 克也
8番 (中) 松井 秀喜
9番 (遊) 松井 稼頭央
No.161
そろそろ言ってた3ケ月だねぇ
戻ってきたら笑うけど
No.162
>>59

> 5chの場合は書き込みが永久に残り、読み返されることは認識しておいた方がいい。
けだし名言であるな
No.163
やはりgitの思想こそ至高
No.164
至高とは思わないけど、発想の転換みたいなものはあるよ。
小さい規模だと上手くいっても、大規模だと上手くいかないところの解決策になっているところ。
No.165
>>164

Git使ったこと無いし使う気はないけど、そういうことは何となく理解できる
でもここの1の言うゴミ箱のような感覚で使うと便利、の意味は難しくて理解できないw
クライアントごとにIDでも付けて履歴で管理するのだろうか、それじゃ何が便利なのかわからないなって考えがグルグル
結局ツール作るどころかそのあたりのプレゼンや説明すら不十分なのよ。たくさん長文書いてたのにw
No.166
そろそろ名前決まった?
No.167
長文君が言ってたのは汚部屋・ゴミ屋敷の論理なんだよな
「何も捨ててないから必要なモノは全てこの中にある」という
「この中にある」のと「速やかに見つけて取り出せる」の違いが分かってない
No.168
長文君はゴミソフトのエンジンにgit使う予定だったんだろ
エンジンとして使うためにgitを真面目に触ってたら別にgitでいいじゃんということに気付いたんでしょうな
No.169
いやこの人アプリ作ったことないでしょ。プログラムすらできるか怪しい
そんな人がgitを真面目に触ってもわからないのではw
No.170
>>169

広告収入とか働き方とかに夢見ててそんな感じだったね
No.171
名称について無駄にこだわってるあたりからして本当にアプリケーションとか作ったことないんだろうなぁ
No.172
せめてフロントエンドツールの雛形でも示してから新しいアイデア募集するなどしたら筋が通ってたのにな
何もできない人が「こんなもの作ります」って言っても妄想激しい人でしかない
どちらにしてもこの板にスレ立てたら板違いだが
No.173
3月末リリースとか言ってた割にまるで進捗ないのか
口先だけだったね
プライドだけはあるからGitスレにも戻ってこないな
No.174
いやぁ〜Gitって本当にいいものですねえ〜
No.175
Gitベースの日本語フロントツールって需要自体はありそうだから、適当なもの作ってストアに出しとけば売れたのでは
企業ユースだからサポートが火の海になる代わりに儲かるw
No.176
火の海じゃなくて火の車ね
No.177
職場がサポート対応で死ぬほど忙しくまるで火の海になる様子が目に浮かんだのでつい・・・ごめんなさいw
No.178
儲かるのに火の車とは言わないな
No.179
>>108

ここまで長文でグダグダ語っておきながら、まるで要件が定まってないのすごいな
No.180
>>179

「売れるような要件あと2、3個欲しい」で「売れる見込みが無ければ作らない」から「アイデア募集、名前も募集」だからな。甘えすぎていて笑うしかない
個人開発なら自分でまずできるところまで作ってからそういうことやれよと
No.181
ほんとにね
名前なんてあとから決めればいいけど、要件に関してはgitに不満があってこのスレ立てたんじゃなかったのかよw
No.182
ゼロからアプリ作ったことなかったんだろ
No.183
全くできそうにないのに妙に自信もって作るぞスレを立てる間抜けはたまにいるが何なんだろうな
無知からの万能感ならガキにありがちだが、大人になってんなら手に負えない
No.184
gitは神ツール
No.185
もう3月の中旬だけど進捗はどうかな
あ、逃げたんだっけw
No.186
名前なんか考えるよりも手を動かせばよかったのにねぇ…
No.187
もうすぐ3月末なのに進捗報告ゼロ!
もはや勝ちは見えた!
やはり雑魚は雑魚だったのだ
No.188
迫害とか交流とか書いてるけど自分がかまってもらいたかっただけの寂しくて頭弱い人だろ
Gitスレ見たら何度も用途を理解してないこととか説明してもらってるのに、それを「迫害」って言うのは人としてアウト
あげくできもしないelectronでツール作るからとスレ立てるって
できないから文句言われたくなくて結局逃げるしかない
こんな恥ずかしい人にならないように、このスレ見た人は反面教師にするべき
まず「こんなアプリ作ります」スレは板違いだし、立てた人は実現できないフラグがつくのも知った方がいい
No.189
進捗0で期限切れ
No.190
Electron 無理ならMicrosoft Edge WebView2 でよろしく
No.191
まあ長文君は帰ってこないだろうし、スレを有効に使うとしたら誰かがGitのフロントエンド作ってくれることかな
長文君の言ってたゴミ箱のバケツは無視でw
俺はGit使ったことも使うつもりも使う人の気持ちもわからない三重苦だから無理w
No.193
>>191

フロントエンドなんかいらんよ
No.194
>>192

自分で作れ
>>193

TortoiseGit「えぇ…」
No.195
SVNはTortoiseSVN以外から使う気が起きないけど、Gitは逆にコマンドラインからしか使う気が起きない
この差がなにかは自分でもよくわからない
No.196
SourceTree「あの、僕は……」
No.197
履歴
No.198
Git クライアントの雑談に使われているんか
No.199
長文君はGitスレに書いてないで早く開発再開しなさい
のage
No.200
Gitの素晴らしさに気づいたので長文くんは帰ってこないよ
No.201
長文くん不在の間に「Z世代」という言葉が市民権を得だけど、長い間長文くん不在だったんだな。
No.203
長文くんがGitスレに戻ってきちゃった…
No.204
まだ生きてたのねこのすれ
No.205
ニャー
No.206
>>203

Gitスレにはワッチョイもあるじゃん
どこでも同じだけど一人の荒らしだけじゃなく相手にする連中も害悪なんだよ
No.207
長文くんファンクラブを作ってこっちを盛り上げよう。
本家に書かれると、ゴミだらけになって重要な情報が埋もれるので迷惑。
No.208
>>206

そう割れ窓理論ね
No.209
ム板で盛り上がってるスレこんなんばっか
No.210
長文くんがGitスレから消えた?
No.211
長文くんの精神的勝利
No.212
長文くん明らかに後半意気消沈してたね
No.213
長文君は自分の醜態をみんな忘れてくれてるはずと思って出てきたけど
忘れてくれてなかったということなんだろうな
長文君曰く
「5chの場合は書き込みが永久に残り、読み返されることは認識しておいた方がいい。」
No.214
おちんちん力を高めたいです
No.215
伽藍とバザールの話もろくに通じない長文くん
数十年前の論文を読むところから進めてほしいものだね
No.216
Gitスレ荒らす長文君はクズでこのスレを上げるのは板を荒らすクズ
No.217
修正の指示や理由の説明をするのが reviewではないのか
No.218
長文くんが登場して伸びたのを期待したけど違ったでゴザル
No.219
>>217

Gitスレでの事をいってるんなら、PRにおけるChange RequestやCommentと具体的に
書けという意味ではないだろうか?お作法スレではなくGitスレなので。
No.220
長文くんと呼ぶと気に障るようならバケツくんと呼べばいいのだろうか。
本家に登場したみたいだが。
No.221
Gitスレで「Git信者とは会話は無理」という、ちょっと誰か通訳してくださいレベルの意味不明発言して消えたな > 長文くん
No.222
もうすぐ1周年
No.223
もういなくなっちゃったのかね
Gitスレにもいない
寂しい😞
No.224
忘れていた。すっかり。
きっと身の程を知ったのだろう、と煽ってみる。
No.225
ゴッミバケッツに期待してたのに成果出すこともなく隠れてんのか
残念な奴だな
No.226
1年くらい前に終わってる知恵遅れの立てたスレをわざわざ蒸し返す知恵遅れ
No.227
知恵遅れのためにお節介な暇人が立てたスレじゃなかったのか
知恵遅れが立てたの?
No.228
>>227

>>1
や同じIDの書き込みからいって後者だろ
No.229
住基文字をJIS範囲にぶち込むとか素人みたいな業者だな