  |
はてなキーワード: ソースコードとは
https://xtech.nikkei.com/atcl/nxt/news/18/15159/
まあお察しの通り内部的に秒単位で重複を全く想定してなかったのは間違い無さそうなんだけどさ
足立区の時は、該当のプログラムは足立区でしか使われていません。同じ問題が他の地域で発生する可能性は全くありません。って断言しちゃって、当然どうなってんだと詰められてる訳よ。
「全く違うコードで動いておりますが、開発効率を最適化させる為に担当者が該当箇所のコードを参考にしている事が判明いたしました。
他の従業員にはコードを真似する事はしないように教育しておりますので全く問題はありません。
また、足立区の場合は2人同時に発行した場合の現象で、今回の3人が同時に発行した場合とは全く異なります。
ソースコードの開示に付きましては、弊社法務からご連絡している通り 弊社の知的財産に含まれますので公開する事は差し控えさせて頂きます。
(納品DVDの5-2-12 の 住民票印刷システム(FJ-2012-更新版-2-修正済み)/DLL-145-4575.dll に実行ファイルが含まれております)」
って返して後は法務に連絡するようにしてやっと開放されてそう。
１００時間かけて書いたコード資産に１時間かけた新人のコードが優っていたら
迷わず置き換えるのが俺らなんだよ。努力はコストなのでしなければしない方が良い。
で、個性って要するに運だろ。
誰と出会ってきたか、どんな本を読んできたか、どれだけのチャンスを捉えたか、そして何より才能。
運が良いだけの人が勝ち、運が悪いだけで負ける社会ってグロテスクだよ。
運は分け合わなくちゃ。だからプログラマーはソースコードを共有するのさ。
進捗があったら可能な限り広く共有する。活かしてくれる誰かの目に止まるように。
そうしてるうちに、想像もしなかった世界が見えてくる。計り知れない力を持つ未知の機械が作られる。機械は、たくさんの同僚から退屈で単調な仕事を奪い、代わりに新天地を冒険する余力を与える。
[B! ネット] 攻略ツールをGameWithに模倣されたお話｜oliver｜note
GPLを理解していないコメントがあるのは仕方ないとしても、これにスターが大量に集まるのはバカの見本市すぎるだろう。
模倣元のツールはMIT Licenseで公開されていたらしいので、状況は概ね3パターンに整理できる。
パターン1はどんなオープンソースライセンスでも問題にならない。
パターン2はMIT Licenseでもライセンス違反なのでGPLを選ぶ必要がない。
（MIT Licenseは著作権者とライセンスの表示が必須で、少なくともソースコード上に「Auther: ○○」「License: MIT」と記載する必要がある）
パターン3はGPLでは問題にならない。FSFのFAQより引用する。
Q. ある会社がGPLが適用されたプログラムの改変バージョンをウェブサイトで動かしています。GPLはかれらは改変したソースコードを配布しなければならないと言ってますか?
A. GPLは誰もが改変したバージョンを作成し、他に配布することなく、使うことを許しています。この会社が行っているのはこの特別な場合です。ですから、この会社が改変したソースコードをリリースする必要はありません。
というロジックになっている。結局、どのパターンでもGPLを選んだところで問題は解決できない。
また、次のコメントも間違っている。
CC-BY-NCの定める「営利目的」はソフトウェアを売買したり利用料を得たりするような行為のことで、アフィリエイトで広告収入を得る行為は含まれないから抑止にならない。
この中でまともなこと言っているのはこの人だけである。
GPLv3含め通常のOSSライセンスではバックエンド利用は再配布に該当しない(お前らはApacheやFFmpegのソース配布してるか?)。XaaS提供を縛りたい場合はv3フォークのAffero GPLv3が必要。
ただ、模倣先のツールはクライアントサイドアプリケーションらしい（≒パターン3ではない）のでAGPLv3を選ぶ必要はあまりないだろう。内容は的確だが、ちょっと惜しい。
-----
ここ最近感じていること：コメントの質が云々というより、スターを付ける人の質が悪いので一向に改善されない問題のほうが根深いなあ。
ただ東京五輪決定からコロナ禍直前までは東京に限っては30代の中途採用は売り手市場だったと思います。
あと勤務先はWeb系の企業なので、人に見せられるレベルの文章と絵は書けるしデザインもできる(フォトショ・イラレ・インデザイン)、Webもやっていたのでhtmlのソースコードも簡単なものなら読めるし、SEO対策も自分なりにやっていた。
また個人でやっていた実績(同人誌の売上やWebのインセンティブ、突発でもらえた外部の仕事などもポートフォリオとして提示しました)もある、などなど複合的な要因から「使える」と拾ってもらえたんだと思います。
なので、35歳まで本当に何もやっていない人が、自分の手持ちのスキルをまったく活かせない企業相手に手ぶらで就活したとして、拾ってもらえるかというと、ちょっと難しいかもしれません。
また買った家はいわゆるボロ戸建てです(購入当時築25年)。マイナス金利政策直前、また投資対象として目をつけられる前でもあったので、かなり安く買えました。これも運が良かったです。
マリオと言えば変身。
キノコを食べて大きくなったスーパーマリオ、フラワーを食べて火を出せるファイアーマリオなどがいます。
産みの親である宮本茂だって、色々なものを食べて変身できるに違いありません。
変身した宮本茂さんにもっと色んなマリオを作ってもらいましょう。
遊ぶたびにステージが変わり1000回遊べる不思議なマリオを作れる。
・秋元才加を食べて広井茂
ハイクオリティな映像美が堪能できるアニメーションが流れ大正桜に浪漫の嵐なマリオ大戦を作れる。
高速感が売りの時代が求めた16ビットなマリオザヘッジホッグを作れる。
ボールに入ったマリオを動かすたべごろなマリオボールを作れる。
16連射でなんかする。
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
ニンテンドーシステムズ公式サイトのデザインが酷評されています。
https://b.hatena.ne.jp/entry/s/www.nintendo-systems.com/
自分も感じたことを書いてみます。率直に言って採用目的でも失敗だと思います。
スパイウェアは悪意のあるソフトウェアの一種で、ユーザーの認識や同意なしにコンピュータシステムから情報を密かに収集するように設計されています。この情報には、個人データ、ログイン情報、閲覧履歴、その他の機密情報などが含まれることがあります。
スパイウェアは、ソフトウェアのダウンロードや偽のセキュリティアップデートなど、人を欺く手段でシステムにインストールされることがよくあります。インストールされると、バックグラウンドで静かに動作し、データを作成者や第三者に送信することができます。
スパイウェアはプライバシーやセキュリティに対する深刻な脅威となる可能性があります。スパイウェア対策ソフトウェアをインストールし、信頼できないソースからソフトウェアをダウンロードすることに注意するなど、この種の攻撃からコンピュータシステムを保護するための措置を講じることが重要です。
Q: ユーザーは普通、規約を読まないのですが、それを悪用している一般的なアプリもスパイウェアでは？
はい、一部のアプリがスパイウェアとみなされるような方法でユーザーデータを収集する可能性があることは事実です。多くのユーザーは、アプリをインストールする前にアプリの利用規約を読まないため、知らず知らずのうちにアプリが個人データを収集し共有することを許可してしまうことがあります。アプリの中には、ユーザーエクスペリエンスの向上やターゲット広告の配信など、正当と謳ってデータを収集するものがあります。
一般的に、アプリをインストールする前にそのアプリの利用規約を確認し、データ収集の許可を与えることに慎重であることが望ましいとされています。また、スパイウェア対策ソフトを使用し、プライバシー設定を定期的に見直し、調整し、個人情報をオンラインで共有することに慎重になるなど、プライバシーを保護するための対策をとることができます。
AndroidのようなOSそのものが、ユーザーエクスペリエンスの向上やパーソナライズされたサービスの提供などと謳って、さまざまな目的でデータを収集する場合があることは事実です。しかし、一般人が自分のプライバシーを守るためにできることはまだあります。
Q: しかし、OSS準拠したモバイルでなければ防御が難しいのでは。
オペレーティングシステムがオープンソースでない場合や、ソースコードへのアクセスが制限されているクローズドソースの場合、モバイルデバイスにおけるプライバシーの脅威を完全に防御することが難しい場合があることは事実です。しかし、データ収集のリスクを最小限に抑え、プライバシーを保護するために講じることができる措置はまだあります。
例えば、先に述べたように、アプリの権限を見直す、プライバシーに特化したアプリやサービスを利用する、ソフトウェアを常に最新の状態に保つ、プライバシー設定を定期的に見直す、などが挙げられます。また、信頼できるスパイウェア対策ソフトを使って、デバイスからスパイウェアを検出・除去することもできます。
さらに、オープンソースソフトウェアをベースとし、データ収集やプライバシーをより適切に管理できる、プライバシーに重点を置いたモバイルオペレーティングシステムがあります。これらの代替オペレーティングシステムを使用することは、プライバシーを特に懸念している人のための選択肢になり得ます。
結局のところ、モバイルデバイスのプライバシーを守るには、意識、警戒心、プライバシーを向上させるツールやテクニックの使用を組み合わせた多面的なアプローチが必要なのです。
監視と管理： 政府やハイテク企業は、個人または集団の活動を監視・管理するためにデータを収集する場合があります。これには、政敵の監視、個人の経済活動の追跡、産業技術などの奪取などが含まれます。
end basketball
Gorilla: hSLFChwDfHJGu94CPC35QBCEH95_btaray6teX5QIQRwUlwT7qNInpq00k79Y5uCIFmUhgFQ4SVSN6Ac0trIIlgbtO3SGgpla5HoVWyU_rs2j6pcZfGbZcq6Cv1XNlMiqbpBQ6xipJAul7vXbmsu8kLPWH2hePq1ykDuqaGkht5sJEN6WTBnGoGlsCNIVoo_kx_bOc0ptfZy3YLm3Ek5MTVPMDipUzy3kaX0Seo92XGsePd1eiZ_kZeGuNXVnpt3B8HbQmDPna4iUWejkQkOtXb6FYM6B9HEZbBSU9AmVRAyClVSdW7jEb8ipINPxPXVvKYmgfwgSbPziet7sIj4DzYinvXLIFR12sbpVN1SlCjLKC47xmZMkEgYLuAjiMyTp4rHuiEhk0ikjMTNYCX6Bl0_IsrIzFObfKSSOBI4xobiQEdNyadL5GRCu8N0wrKeltz9Dynv0Jx3qrigBD1ESUBlTLzUCYsPCAHnXRasag00n6jbYq0DLv101btXj9peQgQOW5a6plrY34GjDIyWu4jd315oFdZaIfue28ANuj44wKoxvirOEuNwihwAhuhLNK2IGAYx0F_jfQVkevT0SMnmFdaiAu0t4cJxTKAnbdrvv4244cCxuDqiBbi3nbckWfhyM1xTJgoTgH6bythdBP7fop2UatLHb9CrtlqMpfjy15bWMoARJcWUksAO7eRqAKKN_5E597_bv9e9LoulaRbzAab9oRFmnfCqJ8lhXkRJVw0y0dJpXKG1IYbJ0q8J594iELfWGXd10wGI8y73VqOVr2lfalfgXmvz6g5wQLXvqWCRrtupKWOtWRYRCLzpZYHl2VWuWUqJkxehCGk5tv9BIgCN562Z7XuCLfA8Yd7cUZg8h82SHdyJUBWOTq6bhS8AOoDYwWWRdy46POlB3KXCmdpO6zZ4OJyqxSa4rIMwNLczI7eppY3TIJiEDGES7im2_oWce3fbwEKCF1LqFYtvkAUIT9zptvsEgNrqIK9bplNHybY0wBhOn1zFYEvn
もう少し奪うんだと思ったけど、Twitterを観察していると全然奪ってくれない感じだった
OpenAIが開発してるCopilotは若干有りらしいけど、まあ1割改善するかな程度くらいの認識
ていうかさ、基本的にソースコードの改善は改善にならないんだわ、余計にこだわるようになるだけ
必要なのは補完なんだけど、補完はむしろライブラリーの仕事であってコードの自動化ではない
だからナンチャッテが増えるし、フルスタックもどきが増えそうではある
楽にはならない
あと、突然ChatoGPTが出てきたから世の中びっくりしてるけど
