  |
はてなキーワード: ソースコードとは
嘘松プログラマーさんこんにちはーwwwwwwwwwwwwwwwww
またまたでてきたねーwwwwwwwwwwwwwwww
君たち嘘松プログラマーの特徴を言うねwwwwwwwwwwwwwwwwwwww
それはーwwwwwwwwwwwwwwwwww
会社で作ったプログラムのソースコードを絶対に書かないんだよねーwwwwwwwwwwwwwwwwwwwwww
更に今回で言えばーwwwwwwwwwwwwwwwwwwwwww
今までいた会社名や君の名前や相手の名前とか全然書かないんだよねwwwwwwwwwwwwwwwwwwwwwwwwwwwww
なんでかななんでかなwwwwwwwwwwwwwwwwwwwwwww
それはなんとwwwwwwwwwwwwwwwwwww
嘘松だからですwwwwwwwwwwwwwwwwwwwwwwwwwwwww
ねえねえwwwwwwwwwwwwwwww
いい加減本当松がみたいなーwwwwwwwwwwwwwwwwwwwwwwww
あー無理かなwwwwwwwwwwwwwwww
ここ数日、エンジニア界隈で話題になっている「雑魚エンジニア」の記事がある。
https://note.com/joan_of_arc/n/ned510ca913c7
中身は「自分が無能だったせいで最終的に鬱になったので経緯を説明します」ってだけなんだけど、
これを読んで思ったことを書き記す。
そこで、頭の至らない私にとって選択できる解決策はあまり思い浮かばず、「第三者に判定してもらおう」と思い、ソースコードの一部を私の部の slack に共有し「このコード、率直にどう思いますか？」とお伝えしました。
いやいやいやいやいや、コイツやべーだろ！
ウンコードを読んでリファクタしたいと思ったのはわかる、それを断った先輩の気持ちもわかる。でもその後のアクションがなんでいきなり晒し上げなんだよ！
それ社会的に殺したい相手とかにやるやつだから！同じ会社で一緒に働く同僚にすることじゃねーから！
ってかもう、この部分だけで彼(彼女？)の生態がわかるじゃん。
文中では
とか
この記事も徹頭徹尾、「自己の正当性を証明するために世間の同意と同情を得るためのもの」じゃん。
話は変わるけど、君らは当然ハリーポッターは履修してるよな？してる前提で話を進めるよ？
「ああハリーポッター、ドビーめが悪いのです！」とか、「ドビーは悪い子！ドビーは悪い子！」とか。
この記事も完全にそれじゃん！
自分のことを「雑魚エンジニア」とか「頭の至らない私」って過剰に卑下してみたり、
「自分視点の主観的な理解しかお話しすることができません」とか「この先輩エンジニアの方に責任を押し付けたいわけでは決してないです」とか「『上司の判断がおかしい』と言いたいのではありません」とかで免責してみたり。
こいつはくせえッー！ゲロ以下のにおいがプンプンするぜッーーーーーッ！！！
雑魚エンジニアじゃなくて屋敷しもべ妖精エンジニアに改名した方が良いと思う。
今回は鬱になっちゃったので失敗感あるけど、これまでこの「周囲を味方につける」手でたくさん成功体験を積んできたんじゃないかな。
相変わらず、綺麗なコードに夢見て失望する若手プログラマーがいるみたいだな。
現場には有象無象の増改築で小汚いパッチワークと化したソースコードしかないっていうのに、なんで未だにそういう奴がでてくるんだろうな？
やっぱり、マーティン・ファウラーやらロバート・マーティンやら、『ハッカーと画家』『UNIXという考え方』やらを読んで、プログラミングに芸術性を見出しちゃうのかな。
ああいう、プログラマーというものにおかしな夢を抱かせる本は悪書なんだから、若手に進めないでほしいね。
人間の慣れっていうのはすごいもんで、どんなに汚いコードでも一ヶ月、二ヶ月と付き合ってるうちに普通に読めるようになってきて、綺麗なコードと大差ないくらいの生産性を出せるもんなんだよ。なんなら変に高尚なテクニックを使ってないぶん、汚いコードのほうが読みやすい、なんていう倒錯も起きる。
で、そういう慣れたら読める程度のコードを「リファクタリング」と称していじくり回すことに何の価値がありますか、っていう話だよ。それはビジネスバリューを産みますか？ お金になりますか？
っていうね。
コメントつけないとまともに読めないというが、コメントつけたら読めるならそれでいいじゃないか。そっからリファクタリングをわざわざしなきゃいけない必然性はどこにあるんだ？
もちろん、中にはまともに改修できない下痢便のようなコードもあるが、それはごくまれで、どんなに汚いコードでもコンパイルできる以上はちゃんと文法に則って書かれてるんだから、丁寧に読んでおけば読めるもんだ。
別に汚いコードのほうがいい、って言ってるわけじゃない。コードが綺麗であるにこしたことはないだろう。ただ、君の頭の中で輝く綺麗なコードってのは、そんな大層な価値があるものじゃないんだよ。
という話を、プログラマー業界の偉い人がもっと発信してほしいんだが、誰もしてくれないよね……。頭でっかちの若手三年目くらいがみんなぶつかる話なんだから、教えてあげればいいのに。
これは理路が悪い
AI絵の話の問題は、素材として自分の権利コンテンツが使われている事だ
学習モデルをきっちり指定すれば、ほぼほぼ狙った絵柄の絵を出力できる
これと同列に語るためには
パワプロのソースコードが学習として取り込まれて「そこから」ウマ娘のコードが出力されてる位の相関が必要だ
パクリって話なら、RPGなりSTGなりの「システム部分」はパクリなしに成立しない
トレースでなく努力の結果、目指した作家と絵柄が似た人はパクリか？
という話をしたとき、KONAMIは「特許侵害」というステージで問題にした
これはパクリだとか似てるだとかそういう次元の低いお気持ちの話じゃない
ノベルゲーが隆盛を極めた頃、そのシステム構成や物語構成（日常、個別、問題発生、解決）がパクリなんて言われたことないだろ
程度の低い話すんな
後弾になりかねないぞ
Photoshopのタイル構造はどのように実装したら良いですか？何か参考になるソースコードなどはありませんか？
Photoshopのタイル構造は、画像を小さな矩形のブロックに分割して、各ブロックを個別に処理することで実現されます。これにより、大きな画像の処理を高速化することができます。
このアルゴリズムを実装するには、以下のような手順が必要になります。
画像を読み込む
処理が完了したら、結果を保存する
以下は、Pythonで実装された簡単なタイル構造のコード例です。この例では、画像を単純にグレースケール化しています。
import numpy as np from PIL import Image # 画像を読み込む im = Image.open("input.jpg") # タイルのサイズを決定する tile_size = 128 # 画像をタイルに分割する tiles = [] width, height = im.size for y in range(0, height, tile_size): for x in range(0, width, tile_size): box = (x, y, x + tile_size, y + tile_size) tile = im.crop(box) tiles.append(tile) # 各タイルを個別に処理する for i, tile in enumerate(tiles): tile = tile.convert("L") tiles[i] = tile # 処理されたタイルを結合して、元の画像を再構築する output = Image.new("L", (width, height)) x = 0 y = 0 for i, tile in enumerate(tiles): output.paste(tile, (x, y)) x += tile_size if x >= width: x = 0 y += tile_size # 結果を保存する output.save("output.jpg")
このコードは、Pillowを使用して、画像の読み込み、タイルの分割、処理されたタイルの結合、結果の保存を行っています。このコードを改良することで、より高度な画像処理アルゴリズムを実装することができます。
回答ありがとうございます。しかし、実際にはこれに拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などが加わります。拡大縮小は画像ピラミッドのようなもの、メモリ以上の巨大な画像を扱えるのはmmapを使っているのではないかと予想しています。これらを一言で回答するのは難しいと思いますが、何かアドバイスをいただけないでしょうか。よろしくお願いいたします。
拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などを実装するためには、より高度なアルゴリズムとテクニックが必要になります。
拡大縮小に関しては、画像ピラミッドを使用することで実現できます。画像ピラミッドは、複数の解像度レベルで同じ画像を表現する方法です。画像ピラミッドを使用することで、拡大縮小のプロセスを簡単かつ高速に行うことができます。OpenCVやPillowなどのライブラリは、画像ピラミッドを構築するための機能を提供しています。
タイルを跨いでのコピー＆ペーストは、オーバーレイ技術を使用することで実現できます。オーバーレイとは、複数の画像を重ね合わせることで、新しい画像を生成する技術です。タイルを跨いでのコピー＆ペーストは、オーバーレイを使用して、複数のタイルを重ね合わせることで実現できます。また、透明度を使用することで、重ね合わせたタイルの一部を透明にすることもできます。
ペンツールでの描画に関しては、画像のピクセル単位での操作が必要になります。これは、OpenCVやPillowなどの画像処理ライブラリを使用して実現できます。画像のピクセル単位での操作には、色の変更、描画、消去などが含まれます。これらの操作を組み合わせることで、複雑な描画機能を実現することができます。
最後に、メモリ以上の巨大な画像を扱うために、mmapを使用することは可能です。mmapを使用することで、ファイルをメモリ上にマップし、ファイルと同じようにアクセスすることができます。これにより、ファイルがメモリに収まらない場合でも、ファイルの一部をメモリにマップし、必要な部分だけを読み書きすることができます。ただし、mmapを使用する場合は、適切なメモリ管理が必要であり、オーバーヘッドが発生する可能性があるため、十分なテストと調整が必要です。
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等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
