  |
はてなキーワード: ソースコードとは
もにょる～～～絵柄は著作権法で保護されないけどプログラムのコードは著作権法で保護されるのよ～～～
著作権法で保護されていて勝手に使ったら違法のところを許可するのがライセンスなのよ～～～
https://x.com/33ki/status/1857362511286407385
反反AIで特に絵に対して文句をいっている人って、絵描きに対してコンプレックスがあるか、AIで絵を描いて儲けたいとか何かのポジショントークとしか思えないところがある。
例えば DeepL とかの AI ベースの製品も入力内容を学習に使わないオプトアウトができるようになっている。
X とか SNS に載せたらそれは学習に使いますと言われたらそのSNSを使わないという選択があってもよい。
そこを学習は合法だからと連呼するのは、会社のデータをなんでもかんでも外部のサイトに提供してお漏らしすることが許されている会社なのかな？AI の発展のためにおまえのデータをすべて開示すべきとかいってる奴は働いたことがないか、やっかみか何かか？と思ってしまう。
クロール防止を避けられてしまうならウォーターマークなどで自衛するしかないだろう。これは生成AI以前でも行われていたこと。難易度を少しでもあげLORAされにくくする、学習に時間がかかったり手間がかかるので悪用する利益に見合わないと思わせるようにするというのは問題ない。
現代の暗号化も素数とか計算に時間がかかることに依拠しているものもあるように、現実的な時間というのは重要なファクターなのだ。
これは絵だけでない。声やテキスト全ての学習されたくない情報をどうやって学習させないかをちゃんと考えて一般の人に広めるのは個人情報保護のように今後リテラシーになっていくのかもしれない。なので学習されないようにしていると冷笑するのではなく、安全な公開方法を用意したりする仕組みを考えるべきなのだろう。
あの法律、生成AIをあまり想定してなかった、かつ一度決めたら引っ込められないお役所仕草が相まってると思うのだよね。
AI にも色々あって画像認識、背景削除など色々使える。GenAIと違いこれらのAIは基本的に学習した結果がそのまま出力されない。このように使われるなら納得されるだろう。
一方GenAIは学習結果から同じフォーマットの成果物を出してしまうのが問題。画像生成は学習したデータを元にした画像しか生成しない。LLMもニュースや過去のデータを元に回答している。それらには本来権利があるのに無視してしまっている。
声優の話や、海外の getty やニュースサイトの訴訟とか、今後法律も変わってくると思う。
EU なんかは学習元データ開示させようとしてるし、アメリカのエンタメ界隈のロビー活動によってはディズニー法みたいに変わることもあるだろう。
特許や著作権同様、国際協調して進めるべき案件だろう。盗まれるならやはり保護技術や法律が必要ということ。
学習速度と生成速度が全然違う。前述のとおり暗に現実的な時間というものが守ってくれていた部分がとっぱわれてしまった。
活版印刷の時に著作権ができたように何らかの制限ができてしかるべきだと思う。
横道にそれるが量子コンピューティングなりで暗号鍵やHashが推測できるようになったら暗号化はどうなるのだろうね。パスワードの解析も人間が考えたものだから解析するのは問題ないとか言うのだろうか。すでに不正アクセス防止法があるが。
そこは同意だがライセンス、特許はあるよね。ライセンス違反をしてコピーをしたら訴えられる。プロプライエタリな製品のEULAだと大体リバースエンジニアリングも禁止だ。
プロプライエタリの製品のソースコードをすべてオープンソースにせよとかおもってるのかな？
音楽は消費するのに少なくとも一曲3分以上かかるし、小説、動画だってもっとかかる。
一方、絵というのは一目で個人的な見解のレベルでは良し悪しがわかる。そのため消費するのに時間がかからない。それなのに人間が作成するには時間がかかるという非対称性がある。
そういうものをAIで数秒に一枚生成されてしまうのだから反発が大きい。
声もそう、その人の声でなにかするというのは一瞬で消費される。一度学習されてしまえば再利用に歯止めが利かない。
消費するために公開せざるを得ないものについても保護できるようにすると言うのは必要。それが著作権以外でもいい。
何でも学習合法にするとDeepFakeや類似作品が溢れかえる。しかも生成は数秒。
それをすべて被害者が訴えて回るのはフェアではない。学習、生成段階で歯止めをかける仕組み、法制度が必要になってくるだろう。
それを合法だから！反AIは異常とか言ってるのはそれはそれで思慮が足りない。
一方、合意して学習した内容を使ったAI、例えば自分の作品を自分で改善するといった分野に使うなら否やはないだろう。
そういった使い方があるにも関わらずAIは悪と言い、企業や個人に突する反AIもあれはあれでおかしい。
とかそういう低レベルの話では無く、書いても書かなくても同じだから。
そもそも読みにくいコードを書く人は情報の整理ができてないからコメントも読みにくい。
「コメント書くぐらい労力少ないし良いのでは？」
という人も多いけど、コメントを書くとコメントが実装とあってるかどうか確認しないといけないし
おまけにコメントが実装と合ってるかどうかは人間がチェックする必要があって機械的にできない。
「最近はChatGPTに書かせてる」
とかいう人もいるし、現にCopilotだとTab一発でコメントを入れられるんだけど
だったら分からないところを読むときにChatGPTに聞けばいいのでコメントの意味が無い。
とはいえ、例えば外部API呼び出しの制約上致し方なくやってるとことか、将来的な方針なんかはコメントで残す方が良いので
注： ！！ 現在はソースコードのみの公開に修正されています ！！
https://github.com/AonekoSS/SDPlugin/commit/e8b650da4e23e8a4ed449a7a43dd4f7e89b95dfe
問題発生時は、ソースコードのみ公開してたのではないし、自分でビルドしてねという形でもないし、午後のこ〜だやLAMEみたいな形にもなっていなかった
セルシスではプラグインSDKのダウンロード時に、使用許諾に合意する必要がある。
そして、その第4条には、プラグインSDKの再配布についての条項がある。
ざっくりいうと、「公式で審査の上で公開する以外の、勝手な再配布は認めない」というもの。
なので、プラグインSDKを利用しようとする以上、この規約には当然従う必要がある。
だが、青猫氏は審査前にGitHubで勝手にSDKを使った自作プラグインを公開してしまった。
それのみならず、「審査が通らなかったら、ソースコードとビルド用バッチファイルの形で非公式に配布する」と
https://x.com/aonekoss/status/1836418339729739860?s=61&t=w77c_83Mc7twk3hZpQ2ZPw
バッチファイルならプラグインとして完成していないとみなせるからOKだろう、という理屈と思われるが、
ということで、この件、AIとか反AIとか一切関係ない話である。セルシスの審査を待たずに公開し、
審査が通らなかったら非公式にばら撒くと宣言している青猫氏と、規約を守れと繰り返すセルシスの話だ。
IT系に勤めてプログラミングをしているんだけど、リーダーが嫌いすぎる。
ちなみに、リーダーは頭はよく経験は豊富なんだけど、癖が強い人間でかなりの不器用。
（以下、リーダー以外に、上司、プロジェクトマネージャーPMが登場する。リーダーは実装方針などを決めるリーダー。）
ガイドラインを作れば全員がそれを守ると思っている。
ガイドラインを作って、それをチャットなどで周知すれば、自動的に全員がそれを徹底すると信じて疑っていない。
例えば、プログラミング上のログの実装方法を決める。ログには個人情報が入らないように配慮すること、とガイドラインに記載する。
すると、ログには個人情報が絶対に入らない、と信じて疑わない。
通常はそれを周知徹底するために、ソースコードレビューなどの際に指摘したりするが、うちはそうではない。
設計書のレビューは何十回とするくせに、ソースコードレビューはなぜか実施しない。
もしガイドライン通りになっていない部分が発覚すると、その実装者に直接伝えずに、その上司に密告する。
実装の認識違いがあっても、直接伝えずに、その上司に密告する。
リーダーなら、認識違いなどをどう今後改善していくか、を考えるのが普通であるが、相手の責任と決めつけて、しかも直接相手に伝えずに、
嫌味ったらしく上司に密告する。
そもそもが、ガイドラインを作ったなら、その内容を説明する場を作るのが普通だが、単にチャットだけで周知する。
ガイドラインを作るのに2週間とか時間をかけるくせに、説明する時間をケチる。
そもそもこのリーダーはコミュニケーションをケチろうとする傾向がある。
なんでもチャットで済まそうとする傾向がある。
ちなみに、新規参入者がいたとしても、周知をしない。
何考えてんだか。
ガイドラインを作るのと、その考え方を周知するのは同時進行が可能だが、
「同時進行しないと間に合わないよ、もっと効率的にできないのか？」などとPMが聞くと、
キレながら、よくわからないことを述べて、無理やりガイドラインを作ってから周知をする。
スケジュールも明示しないので、後の計画は立てられず、しかもガイドラインの作成だけで2週間などかかる。
さらに、容量のいい人なら、ガイドラインを作成しながら、機能ごとの具体的な指摘も整理してすぐにそれぞれの実装者に展開できるようにするが、
リーダーは非常に不器用なので、ガイドラインの作成に2週間、具体的な指摘の抽出に2週間、などの合計4週間かける。
しかもそれだけ時間をかけて作成しておきながら、普通に抜け漏れがある。
ちなみに抜け漏れがあった場合も、自分のミスではなく相手のミスにする。
依頼すれば対応はされるが、実装者はそもそもがレビューが必要かどうかも分からない。
レビューせずに実装することも可能だが、それでミスがあればグチグチ文句を言われる。
もちろんレビューはした方がいいのだろうが、リーダーは頭がおかしいくらい残業をするので、依頼するのに抵抗がある。
そもそもが、ふつうはリーダーの方からレビュー提案するものではなかろうか。
他にも設計方針の考え方の連携なども、リーダーからは実施しない。
聞かれたりすれば、方針を伝えるのだが、自発的には連携しない。
例えば、大規模な追加機能を搭載する際に、その設計を実装者Aが行う。
それをチーム全体にレビューする。
するとリーダーは自分の考えと大きくずれているとして、苦言を吐く。
そして、リーダーとAで再度設計をしなおして、全体設計を作り直す。
初めから、リーダーがAに全体の設計方針を伝えていれば、大きく方針がぶれることなく作業ができたはずである。
しかしリーダーは、資料なしで考え方を人に伝えるのが苦手なので、もしリーダーがAに方針を連携するなら、
その連携用の資料をリーダーはきっと作るだろう。おそらくそれに1週間かかる。
「わかりました。やっておきます。」と言いながら、怒りながら、言葉を区切りながら発する。
ちなみに、深夜2時までの残業はさすがに目を付けられ、周りから厳重注意を受けているのだが、
スキを見てすぐに残業するらしい。
質問をする。それを嫌味で返される。というのはよくある。
「この処理、処理速度が遅くなりますけど、なぜこう実装したんですか？」
「〇〇の理由です。今までの実装は、処理速度をほとんど考慮してなさそうなのに、なぜ急に意識しだしたんですか？」
などのように。
まるで、自分の実装(の方針)にケチをつけるな、と言わんばかりに。
この一件で、もうこいつ(リーダー)には、何も言わないでおこう、と心に決めたよ。
他にも、人のミスを本人(私)が目の前にいるにも関わらず、
こいつが何にツッコむかはよくわからず、ここはツッコむのにここはツッコまないんだ、ということは多数。
「ハーイ！ジョージ！」の頃はまだ良かったんだ
俺もピエロ🤡に扮して「ハーイ！女児ぃ！」とか言たいだけの人生だった
でも、ラストで巨大な蜘蛛が出てきた時点で興醒めですわ、どんなサメですわ
ウソです
ド田舎でMSXに搭載されていたマシン語モニター機能とか使ってマシン語書いてた頃ですかね
文字をレンガ🧱とかに変えて、ロードランナーみたいなの作ってました
ウソです
MSX1以降、大学に入るまで、私はほとんどパソコンを使っていないブランク期間があります
大学に入って、物置からMSXを発見して、当時購入したマシン語入門的な本とか、
MSXのカートリッジの機能を使って電子工作やる本を買ったりとかして、
MSXカートリッジの形状をしたユニバーサル基盤を秋葉原に買いに行ったことから、そこから毎週毎日秋葉原に行くようになります
まだ、オタク系のアニメとか漫画とかフィギュア模型の店とか、メイド喫茶とか、まったくない時代でした
MSXでZ80のマシン語を一通り理解して、MSXカートリッジにユニバーサル基盤刺して、自分で組んだ電子回路をMSXで制御したりして遊んでました
あと、大学入学祝いがPC-9801だったので、それをいじったりもしてました
Microsoft Quick CとかTurbo Cでプログラムを書いたり、Cマガジンを定期購入するようになり、TeXを最初に動かしたのもPC-9801だったと思います
そのあと、米国から輸入したPC/AT互換機を当時のドスパラだったかな？で購入して、私は運が悪いのか、ちょっと色々と酷いのが届いたのですが、
それを騙し騙し使うことにして、Laser 5が販売していたSlackwareのLinuxインストールしたり、DOS/Vで海外のゲームやったり、なんだかんだ楽しかったのかもな
あと、まだアルファ版？だったかんのJavaを、えらい長い時間かけてダウンロードして、それのサンプルをひたすら眺めて勉強したりしてました
CとJavaでソケット使ってネットワーク系のプログラム書いたりとか、簡単なチャットみたいなのとか、JavaだとAWTでGUIまで作れちゃいますから便利になりましたよね
そういえば、前のバージョンのScratchのソースコードをなんか読んだ記憶がある
ただ、自分はBIO100％みたいにもなれなかったし、X68使ってる人たちみたいにもなれなかったし、Lightwave使ってる人たち、新海誠みたいにもなれなかったし、
なんか色々仕事したり、賞をもらったり、色々あった記憶はあるのだけど、何者にもなれなかったし、今も何者にもなれてないままですね、心に刻んでおくよ
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利なIDEが無かったので変数や関数の名前に長い名前を付けると実装が大変で
仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど
Copilotを使える時代にコメントを書く必要なんて皆無だし
仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメントは必要ない
コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLのリンクを貼ったり
「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど
それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル
そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い
「それでも無いよりはいいでしょ？」みたいに言う人いるが逆に問題になることも多い
コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり
ソースコードの修正に対してコメントが修正されていなくて後々で揉めたりする
当然ながらコメント部分にはLintが効かないので（ChatGPT使えば作れそうな気もするが）
チェック内容も増えるし良いことがほとんどない
ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い
まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな
書いたところで誰も読まないのにアホすぎる
でも、ネットやSNSがなければ、俺の人生はもっと充実してたはずなんだ！ってのも、単なる幻想だと思うんだよね…😟
何でもそうだけど、ifを考えるのって人生でもっとも無駄な時間でしょ？
あと、ネットやSNSがなかったとしても、その時代のネットやSNSみたいな安易に飛びつけるものに飛びついてただけだと思うんだよね
自分はネットがなかったら、コンピュータプログラミングを仕事にしてなかったと思うし、
他人のソースコードを読んだり、ネットの向こう側の誰かをライバルにして技術を向上させようと思ったり、そのためにひたすらコードを書いたり、
ギターを買っても、元となる楽曲の音源をレコードやCDでしか手に入れられないとしたら、財力に比例してしまうし、バンドスコア、タブ譜もそう、教則本もそう
演奏技術はどれだけ普段音を聴いているか、インプットしているかにも比例するから、ネットがなかったら、それが財力に比例したままだったと思う
それがサブスクやYouTubeや、厳密には違法だけど自分が採譜した譜面を公開してくれてる人がいれば、それを無償のTuxGuitarで再生できるわけだし、
ネットがなかったら、自分のプログラミング能力とか画力とか演奏力とか、上達しなかったと思うんだよね
あと、今なら生成AIを壁打ちの相手にすれば英語勉強したり、あらゆる勉強の壁打ちになってくれるし、
ネットやSNSがなければ、俺の青春は充実してたはずだ！みたいな発想に、自分はそもそもならないんだよね
だって、俺、子供の頃からスクールカースト最下位側の人間だから、ネットやSNSでpoweredされてなかったら、人生は今よりショボくてつまんなくなってたと思うんだよね
今の状況にまったく満足はしていないし、そうは言っても、こうやって生きていられることに感謝はしてるわけだけど、
私は熟女モノとか人妻モノは眼中にないのですが、なぜだか最近そっち系の作品が多くて閉口しています。
しかしFANZA側の検索システムはNOT検索できるようになっていません。そこで、検索結果から除外できそうなものを除外するブックマークレットを作ることにしました。
さいわい近年は内容の概要文をそのままタイトルにしたような作品ばかりなので、タイトルに含まれるキーワードで除外が簡単にできそうです。
「熟女」とか「五十路」のような単語を含む作品を非表示にしてしまえばよいのです。
javascript: (() => {
const r = /熟女|完熟|熟れ|四十路|五十路|六十路|人妻|奥様|妻|夫|母|ママ|おばさん|BBA|姑|嫁/;
const q = '#list>li';
document.querySelectorAll(q).forEach(l => {
if (r.test(l.textContent)) {
l.remove();
}
});
})();
javascript:(()=>{const r=/熟女|完熟|熟れ|四十路|五十路|六十路|人妻|奥様|妻|夫|母|ママ|おばさん|BBA|姑|嫁/;const q='#list>li';document.querySelectorAll(q).forEach(l=>{if(r.test(l.textContent)){l.remove()}})})()
このブックマークレットで、検索結果に含まれる熟女系作品の数を1/3くらいにまで減らすことができます。
ブックマークレットとは、ブックマークにURLではなくJavaScriptを登録して、閲覧中のページ上で自分（やほかの誰か）が作ったプログラムを実行できるしくみのことです。普通のブックマークと同じようにブックマークバーなどに並べておいて、クリックひとつで呼び出すことができて便利です。
①まず、どこのページでもいいので（今読んでいるこのページでもよい）ブックマークをひとつ作り、ブックマークバーなどの呼び出しやすいところに置きます。
②できたブックマークを右クリックして「編集...」を選びます。
③「名前」欄は、自分にわかりやすい名前に変更します。でも「FANZAフィルター」などあけすけな名前をつけると、誰かに画面を覗かれた時に困りますよ。
④「URL」欄に、上記したプログラムコードを入力します。ただし上記のコードは私向けのキーワード選定になっていますので、ご自身の好みに合わせたキーワード選定をしていただければよいかと思います。/単語1|単語2|単語3/ のように記述してください。
ふつうのソースコードと、改行・インデントなどを省いてミニファイ（最小化）したもの、どちらをコピペしても大丈夫です。
⑦このブックマークレットを起動します。すると、瞬時に検索結果が減ります。
キーワードだけが異なる複数のブックマークレットを登録しておいて、場面に応じて使い分けるなどの工夫もできるでしょう。
上記のスクリプトが何か悪さをするようなものではないことを説明するために、また、JavaScript を学習し始めたばかりの人のために、このシンプルなスクリプトの解説をします。
javascript:
URLの種類を示すスキーム名です。一般的なURLは https: や mailto: などで始まりますが、javascript: と書くと、これに続くコードがプログラムとして実行されます。
(() => {
// 処理
})();ここからが JavaScript です。まず処理全体をくるむ大きなカッコと最後に付け足された () は、自己実行無名関数という形式です。今回のブックマークレットは変数を含みますので、実行するページに元々ある変数たちとバッティングしないようこのようなかたちにします。
const r = /熟女|完熟|熟れ|四十路|五十路|六十路|人妻|奥様|妻|夫|母|ママ|おばさん|BBA|姑|嫁/;
除外したい単語を羅列した正規表現です。個人個人で設定が変わる部分なので、編集しやすいように切り出しておきました。
const q = '#list>li';
フィルター対象とするHTML要素群のクエリーセレクター文字列です。検索結果に一覧表示される、個々の作品要素を選択します。FANZAがシステム改修を行うと変わってしまう可能性がある部分なので、メンテしやすいようにここだけ切り出しておきました。
document.querySelectorAll(q).forEach(l => {
// 処理
});クエリーセレクター q に一致する要素 l ひとつひとつについて反復して処理を行います。
if (r.test(l.textContent)) {
l.remove();
}
もし要素 l 内のテキストが正規表現 r と一致していたら、要素 l を取り除く、という処理です。正規表現 r はキーワードの羅列ですので、テキストの一部にキーワードのどれかが含まれていたら一致したことになります。
はてブの画面って右上あたりにタイトルと一緒に記事の内容も少し表示されてる概要のボックスがあって、ページ開く前にザッと目を通すことが多いんだけど
何故か朝日新聞デジタルの時だけソースコード？HTML記法？みたいなのが表示されてる。例えば
[B! 裁判] 同意の上の性交で避妊を拒んだ男性に賠償命令 「自己決定権の侵害」：朝日新聞デジタル
のはてブだと
","naka5":"＜!-- BFF501 PC記事下（中⑤企画）パーツ＝1541 --＞","naka6":"＜!-- BFF486 PC記事下（中⑥デジ編）パーツ＝8826 --＞＜!-- /news/esi/ichikiji/c6/default.htm --＞","naka6Sp":"＜!-- BFF3053 SP記事下（中⑥デジ編）パーツ＝8826 --＞","adcreative72":"＜!-- BFF920 広告枠）ADCREATIVE-72 こんな特集も --＞\n＜!-- Ad BGN --＞\n＜!-- dfptag ＰＣ誘導枠５行 ★ここから --＞\n＜div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\"＞\n ＜div class=\"p_infeed_list\"＞\n ＜div class=\"
ってに表示されてる（半角の＞と＜はそのまま入力すると増田に反映されなくなってしまうので当方にて全角に手直ししたものになります）
これって、おま環？
画面上でできなくしてもサーバーに直接リクエスト送ってくるからって同じことをサーバーでも実装しないといけなくてすごくめんどくさい
言語同じかつ単純な規則な共通化できたりするけど実際はそうじゃないものが多いし
画面での操作禁止とそれらを無視して編集後のデータだけ送ってくるのだとチェックの仕方も違う
追加できないなら追加ボタン出さないだけで済むが、サーバー側だと送られてきた件数だけじゃなくてもともとあったものと一致してるかもチェックが必要とかそういうの
ウェブのほうが楽だからデスクトップアプリからウェブに移すがここ数年は多かったが本当に楽か？って思う
画面の柔軟性はあるが、そのせいであれこれ細かい注文がついたりしてそれも面倒が増える原因だし
ウェブだとそれが当たり前だからってサーバー側もデータのチェックしてるけどデスクトップアプリじゃそんなことしてなかった
それのリプレースなんだし、別にしなくていいんじゃないかと思う
デスクトップアプリだってサーバーと通信してるんだから直接リクエスト投げれるわけだし
ウェブなら便利な開発者ツールがあるから今送ったものの中身を見てちょっとか書き換えて送るが楽なだけ
デスクトップアプリだってパケットキャプチャしたり、逆コンパイルしてソースコード見ればできるわけだし
クライアント証明書があるから～とかいう意見聞いたことあるけど、ローカルにあるファイルなんだから、直リクエストするときだってそれ使えるよね
デスクトップアプリだと起動後のホーム画面から順番にボタンを押さないと画面を開けない
だから一覧画面で編集ボタンを出さなければその項目の編集画面は開けない
そのせいで一覧画面で編集ボタンを出さないのに加えて編集画面で自分が編集可能かのチェックまで必要になる
めんどくさい
考えてみればURLで直接開けることは要件にあるわけじゃないんだし、URLにマッピングしないメモリ内でのルーティングでもいい気はする
リロードすれば毎回トップページに戻るけど普段使う上でリロードなんかしないし別に問題ないと思う