  |
はてなキーワード: githubとは
・(類似製品の)好きなものの記事に行って嫌いなものの苦言を言う
それが嫌いなら開かず無視したらええねん…ひたすら腐してるのはなんなん…
あなたが望む実現しない要件を何度も挙げて最低条件って言うのは客観的に見て結構恥ずかしくないですか？他のみんなは大多数が興味があって覗いて、少数は内容を批判的に論じるんだけどxlc さんのは内容関係ないよね…？
超バズったからやってきた。とかならわかるんだけど公開ブクマ1桁以内でこういうの言っちゃったりしてるのは当たり屋じゃないっすかね…
なぜコーディングにVSCodeを使うのか。 私がVSCodeを選んだ理由
xlc 2024-03-13
全く心が動かない。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
Atom の作者達が作った Rust 製エディタ Zed (OSS) - Qiita
xlc 2024-02-25
VS Codeが嫌すぎてAtomを使い続けているので同じ使い勝手なら移行を考えるかも。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
保守・理解しやすいコードを書きたい！ 〜VSCode拡張機能で循環的複雑度と戦う〜 - Qiita
xlc 2024-02-23
Atomの開発が終了しVSCodeをインストールした2023年は全くコードを書かない一年となった。それぐらい使いにくい。というか使う気にならんのだがみんなよく使ってるね。今年Atomに戻したらプログラミングを再開できた。
VS Codeの新機能がすごく便利！ ツリービューのスティッキースクロール機能をオンにすると格段に使いやすくなります
xlc 2024-02-15
昨年ほとんどプログラムを書かなかったのはVS Codeにさわりたくなかったから。とうとう諦めてAtomに戻してプログラミングの習慣を取り戻しました。後継エディタにもがんばってほしい。
xlc 2023-02-02
私はこれ https://www.amazon.co.jp/dp/4798067881 を書くのにこれ https://kobalab.net/liulian/ を使いました。
VScodeの設定（setting.json）まとめ【2023年1月更新】
xlc 2023-01-02
VScodeがあまりにも使いにくいので未だにAtomを使ってる。
GitHub製コードエディター「Atom」の最終版が公開 ～8年間の開発に終止符／12月15日をもってリポジトリはアーカイブ
xlc 2022-11-22
VS Codeを起動してみたが、そっと閉じ、使えるうちはAtomを使い続けようと決意した。
Sunsetting Atom | The GitHub Blog
xlc 2022-06-09
はっきり言って、chatgptとか、github copilotには、直せとだけ言って直るような頭のよさはないぞ
正しいか？なんて聞いても同様。見直し法で多少はましになるが、結局最後は自分が見るしかない
それに、複雑なクエリだと途端に精度が悪くなるからな。注意力の限界値が低すぎるねん
パンピーが簡単なのを扱えるようになるのはそうだろうが、300行近い糞長クエリが動いてるようなところも未だにあるんだぞ(泣きたくなってきた)
そんなの、aiは全部読むことさえ不可能だし、他の処理との整合性だって把握しきれない。各部分の目的を推測するみたいなことが極端に苦手だからなあれは
概要：
というかじゃあ君らはChatGPTとか使わないということでいいの？
本文：
前提として，反AI絵師は「自分の著作物を生成AIの学習には使うな」という主張をしているように見受けられて，それ自体は別にいいんだけども他の著作物に対して目端が効いていないように思える，という認識がある．
そもそも人間が生成した全ての創作物には著作権が生じるもので，この観点からは絵も音楽も文章も等しく尊重されてしかるべき．
なんだけども反AI絵師は絵だけを過剰に特権化しているように思える．
この文脈での「反AI」のAIは，ほぼ「生成AI」とイコールという認識なんだが，となると文書生成に対しても反対しなければ筋が通らない．
なのだけれども，ChatGPTに代表されるテキスト生成やGithub Copilotに代表されるソースコード生成（提案）に対しては何も言っていない．
Whataboutismじゃねえか，と言われるかもしれないが，生成AIの代表であるChatGPTにおいてテキスト生成部分と画像生成であるDALL-Eが並列にメニュー上に存在している以上，そこを完全に別物だと主張するのは無理がある，と考える．
というかChatGPTに「こういう画像を作りたいのでDALL-Eに渡すプロンプト生成してくれ」って指示も可能だしな．
というわけで，この文脈で「反AI」と言った場合，画像生成とテキスト生成の両方に対して反対の立場に立っている，立っているべきである，というのがここまでの話．
で，生成AIは何もないところから生成できるわけではなく，学習するデータが必要になる．
反AI絵師はそこで「自分の画像を使うな」という主張をしていると理解している．
別にそう主張しても構わないとは思う．
思うんだが，じゃあテキスト生成もソースコード生成も，さらに突き詰めると検索エンジンも使うなよ，というのがここからの話．
テキスト生成も画像生成と同様に学習するテキストが必要になる．
で，そのテキストをどこから持ってきているのかいえば，インターネット上に存在する文書となる．
そして（大抵の場合において）インターネット上に存在するテキストには作成時点で著作権が発生してて，それを勝手に学習してテキスト生成に使っている，というのが現状の生成AIがテキスト生成を行う場合の振る舞いとなる．
上記の文における「テキスト」を「画像」に置き換えたものに対して反対の立場を取っているのが反AI絵師，という理解なんだが，であれば当然テキスト生成に対しても反対すべきだろう，と思う．
思うんだが，本当にその辺は反AI絵師はどうでもよいらしく，ChatGPTとそれに付随するDALL-Eも特段の問題としていないように思える．
一貫性の観点からは，著作物に対して同意を得ていない学習に基づく生成全てに対して反対の立場を取るべきでだろうと思えるのに，反AI絵師は画像生成以外を問題とせず，よく分からない特権を振りかざしているように思える．
絵を描く人間だから画像生成以外に対しては放置する，という主張なのかもしれないが，生成AIの生成対象が拡大している現状，その主張は「彼らが最初共産主義者を攻撃したとき」と変わらんのではないのか．
そもそも，Google検索の最初のバージョンはPageRankベースだったわけだが，これは「多くのWebサイトからリンクされているページは価値が高い」という尺度に従って構築されている．
あるページにリンクを張る，つまりリンク先のページに価値があるのかを評価するのは，リンクを張った人間であり，つまりその価値を生成しているのは人間なわけだ．
そして人間が生成した価値をもとにリンク先のページの評価を決める，というのはつまり複数の他人の脳みそのいいとこどりをしているに他ならない．
生成AIに反対するのが「自分が描いた絵にフリーライドして価値のある絵を生成しているのは許されない」という主張であるのならば，他人の脳みそにフリーライドしてページに価値を付けている検索エンジンも同様に許されないものであるべきだ．
これは「生成AIの反対するならば検索エンジンも使うな」という主張の根拠になる．
別に本気で言ってるわけではないんだが，反AI絵師がどこまで考えて主張してるんだろうか，という疑問はずっとある．
1. 反AI絵師の主張を丁寧に拾ったわけではない雑な話なので「藁人形論法」と言われたらそうかもしれん
2. 「反AI絵師」の「AI」が指し示す対象が「生成AI」ではないかもしれん
ただし著作権の適用対象の公平性の観点から「画像生成AI」に限定した議論を特別視できる理由はない
個人的には画像周りへの対応は，検索エンジン避けみたく「画像生成の学習に用いられることに同意しません」みたいなタグを埋め込む形での対応になりそうな気がしてる．
そしてそのタグが普及せずになし崩し的に画像についても生成AIが一般化するんじゃねえかなあ．
あと，「現状，PageRankそのままでは使われなくなってねえか？」という主張は妥当なんだが，だからといって何もかもが変化したわけではない．
結局人間の脳みそにフリーライドするのが一番効率いいのには変わりないしな．
Github Copilotは優秀だけど，だからといってあれがpilotになるわけではない（正解「案」を提示するのと正解を提示するのとの間にはマリアナ海溝よりも深い溝がある）のと同様に，画像生成も人間のそれを（少なくとも完全には）代替できねえんじゃねえかなあ，と思う．
上記の文章は最近うだうだ疑問に思ってたんだけども，「絵師の立場から言いたい「反AI」の人の態度について（https://note.com/magic_clover2991/n/n0ec2827346af）」読んで，頭の中の整理も兼ねて書くか，という気持ちになったので書いた．
github private repoにpdfぶちこんでおけば、
github siteでpdf閲覧できるけど、まどろっこしいばあいは、ローカルにDLして
閲覧すればいいんだ！
というか、あめがふってきた＿|￣|○
べつにおどろくことでもなんでもないけど、honkitできた！
Node.jsがらみのツールらしい。これってのもはじめての経験だ。Node.jsとはjsの開発環境のこと？なんじゃ？IDE？
ディレクトリーに適当にマークダウンファイルやjsonファイルをおいておけば、HP作成してくれた。htmlタグをベタ打ちするのも、いやだった。だからよかった。
さいきん、ベタ打ちすることないし、といっていちいちpandocとかで変換するのもめんどうだし・・・よかった。
いまのところ、git repoでもなんでもないフォルダーにマークダウンファイルなどをおいて、honkitでウェブファイル作成してから
そいつをエイヤーっとgit repoに動かして、git push でリモートにもっていって、さらにgithub pagesでHPにしているけど・・これって
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
とか言ってる奴は50%ぐらいの品質の命名規則やアルゴリズムになってる
経験上、チームなり会社なりのIT能力を計る最も有用な指標は「チャット頻度」
SlackだろうがTeamsだろうがなんでもいいんだけど
チームのIT能力が高いかどうかはチャット頻度が高いかどうかと明確に連動していて
フルリモートでゴリゴリのIT開発系は毎日のチャット頻度が凄まじく多い
これは業務内容だけじゃなくて「雪降ってきた！」とか「腹減ったー」みたいな話も含む
フルリモートじゃなくて出社してるようなチームでもIT能力が高いとめちゃくちゃチャットする
なんなら机が隣通しでもチームチャットに書き込む
これが逆にIT能力低いとフルリモートでIT開発系でも全然チャットを使わない
定期会議や対面を重視するし誰かがチャットで呟いてもなんの反応もない
悪意があるとか関係なく単に「チャットをする文化が無い」からチャットしない
こういうチームはOneDriveやSharePointも使いこなせないしDropBoxやGitHubも使えない
タスク管理ツールも使いこなせなくてとにかく共有フォルダとエクセルでどうにかしようとする
みたいなことを言う人は使いこなせてない証拠
とはいえ、チームメンバーが増えるほど使えない人は出てくるので
結果的にそれが正解、みたいなことが起きてる
