  |
はてなキーワード: ライブラリとは
JavaScriptが人気でGASとかVBScriptでローコードで書くのがメインでPythonとかC#とかサーバサイドとか多かった自分はスピード感に付いていくのが辛い
JavaScriptってみんなどう覚えた？自分は資格試験とか経由で覚えたり業務で覚えたりと後から付いてくる感じで一から覚えるの苦手
あと応用やOracleSilverやAWSのアソシエイトやLPIC2とかよりPMPの方が評価されるのね。自分でも中途半端だとは思うけど高度やGoldやプロフェッショナルって難易度カーブ急すぎるよ
はてなの強強エンジニアには鼻で笑われるけど同世代の中途半端エンジニアはどう過ごしてるか知りたくて書いた
会社の相談員に聞いてもあなただけの仕事言うけど、ライブラリとPaaSがこんだけ発展したらセンスとスピードある奴がいい感じでやるからどっちも無い俺は悩んでるんだよ！って言ったが通じなかった
有名ライブラリを批判すれば権威性が上がると思ってるのか知らないけど
フロントエンド界隈では~~は技術的負債（になり得る）という言説がかなり短い周期で同じライブラリに対して繰り返し行われる
批判する人間が代替となるライブラリを作るならまだ健全だが、コイツらはそんなこともせずにシレッとそのライブラリを仕事で使っている
ハッキリ言ってこの人たちは全員気色悪いしフロントエンド界隈のレベルが低いのもこういう人間の声がでかいからだ
フロントエンドの流行が早く見えるのは確かだが有名ライブラリはきちんとメンテされてるし使い続けても殆どのケースにおいて問題はない
経年して流行から遅れただけでやれ技術負債だのほざいて下らない戯言を撒き散らすのをいますぐやめろゴミ共
ある方が「遺書だったもの」というブログ・エントリーを公開してはてなブックマークで注目を集めています。
https://kirimin.hatenablog.com/entry/2024/09/04/001242
一読しただけで大変な状況の中ご本人が精一杯頑張ってきたことが伝わってきました。
普通の人は不登校になったあとに就職したり（それもB社側からの打診で正社員に！）、アメリカ出張、趣味でイラストや競技プログラミング、といった活動は出来ません。
なにより踏みとどまるという意思を持たれていることが一番素晴らしいと思います。
ブログの内容について、アドバイス、というより考えてみるきっかけを提供できればと思い、以下に書いておきます。
"アドバイス"という言葉は上から目線のニュアンスがあるため私は嫌いですが、分かりやすさのためにあえて"アドバイス"と記載しております。
"アドバイス"の手がかりとして、世の中の多くの人たちと異なっている点を特徴として捉え、そこに着目して述べていきます。
多くの人は、自死を取りやめた場合は遺書を公開しません。ここが最大のポイントです。
他にも、元カノの話や学校で友達を作りたかった話、インターネット掲示板、会社の同僚との関わりなど、コミュニケーションについて多く言及していることもかなり特徴的です。
心理的な安定のためには、インターネットで構わないので、コミュニケーションの場への参加を増やしてしてみると良いかもしれません。
私も同世代で、2005年～2007年ごろには2chで政治家をおちょくるコラージュ写真を作って遊んでいたので、当時の雰囲気は知っています。当時と似たコミュニティはもはやほとんどなく、ネット掲示板よりもLINEのオープンチャットあたりのほうが雰囲気が近いかもしれません。
仕事やそれに近い競技プログラミングの能力・モチベーションでご自身の価値をはかる表現が目立ちます。
仕事への情熱はご自身の能力開発、社会貢献、金銭獲得のために素晴らしいことです。
一方で能力・モチベーションで全人類のトップに立つことは出来ない以上、どこかで自分の能力に見切りをつける必要があります。
それが今なのかな、と漠然と感じました。
人には能力の限界・投入できる時間の長さの制約があり、その制約のもと各自それぞれのペースで頑張るしかなく、他に選択肢はないため、ある面で人より劣ることを認めざるを得ません。
しかしだからといって人間として価値がないとか、死ぬべきだということは論理の飛躍です。
劣ることを認めたうえで、それがどうした、自分が死ぬ必要はないじゃないか。むしろ優れた人たちが素晴らしい社会を作ってくれてありがたい、と感謝すればよいと私は思います。ご自身にもその気持があるはずです。その証拠にA社のリーダー、B社のプロダクト、元カノ、といったものを称える文章があります。これは称賛の気持が奥底にあるからだと思います。
というより本当は人間という存在自体が自他に価値を評価される必要がなく、各自勝手に生きて構わないと私は思います。評価という行為自体が発生しないのが通常の状態であり、仕事では給料の分配という特別な目的のために上司が評価するという例外的なシチュエーションが発生していると私は理解しています。つまりそもそも職場以外での「自己評価」は必須ではないと私は考えています。
そのうえで、それでもなお自己評価が必要であれば、いくつもの会社で働くことができ、しかも先方から声をかけてもらっているというのは素晴らしいことだと思います。普通の人には声をかけませんよね。仕事の以外の面に目を向けると、イラスト、VR、他の投稿ではお母様にテレビゲームを教えたりと多方面に活動している点が素晴らしいと思います。競技プログラミングで高レート帯の方々はこうした活動と両立できるのでしょうか。ほとんどNoだと思います。総合的に見れば特別劣っているように私には見えません。
この点は次の第3の特徴に続きます。
文章には「多くの人から嫌われ、失望され、迷惑をかけながら生きていたくない。」と書かれています。
しかしきりみんさんは、嫌われている人・失望されている人・迷惑をかけている人に対して、死ねとは言わないと思います。そういう人柄だと文章で分かります。
それなのに自分に対して厳しいのはダブルスタンダードで、ご自身を不必要に傷つけているように見えます。ご自身に対して厳しすぎるダブルスタンダードを持つ理由は何でしょうか。ダブルスタンダードを持つメリットはあるのでしょうか。これについて考えると楽になれる部分があると思います。
きりみんさんは、自分より仕事ができない人に死ねと言わないと思います。競技プログラミングが下手な人に死ねと言わないと思います。その理由は劣っていても死ぬ必要はないとご自身が理解しているからです。そうであればきりみんさんが死ぬ理由もないと私は思います。
昨年、一念発起して100kgの大台から70kgまで、30kgの減量に成功した。
やたらと知見を共有したがるのはエンジニアの美点の一つだが、私もその例にならい、ここにダイエット中に学んだことを共有しようと筆を執っている。
ダイエットとはそもそも、日常の食事のことを指し、それが転じて食習慣の適正化を意味するようになった。
減量の本質もそこにある。
人は食べたものからできている。食習慣を適正化すれば、自然と健康的になる。
30kgもの減量に成功した最大の要因は、自分がエンジニアであったことだと思う。
そもそもプログラミングとは、入力されたデータに対して任意の出力データを得るために加工する、その計算方法を設計し、実装することを指す。
料理もまた同じで、食材という入力に対して、調理を実施し、料理という出力を得る。
そのため、体重と食習慣の適正化というプロジェクトに対して、プロジェクトのマネジメント手法が応用可能なのだ。
メモリ4GBのオンボロPC抱えてパイプ椅子で開発すすめても、ろくに進捗しないのと同じだ。
ただし、闇雲に金をかければよいというものでもない。投資すべきものというのは、だいたい決まっている。
どれも無くても減量自体は可能なものばかりだが、あったほうが効率が良い。
そもそも減量はモチベーション管理のゲームなので、自動化、簡易化できるところはやったほうがいい。
金を払って健康を買っていると考えればよい。
まったくアーキテクチャを考えず、行き当たりばったりでファイルごとに違う設計のプロジェクトは悲惨な結果を招く。
最初にこのアーキテクチャで行くと決め、ひとまずはそれを続けることが大事だ。
減量で言えば、ローファットでいくかローカーボでいくかということだ。
日によって低脂質でいったり低糖質でいったりするのは全く良くない。
自分は低脂質でいくことにした。そのほうが筋肉量の減少を抑えられるし、コレステロール値の改善にも効果的だからだ。
金融系プロジェクトにありがちな細かすぎるコード規約は有害無益で時間と金の無駄だが、余りにフリーダムなのも混乱のもとである。
減量でいえば、目標カロリー量とPFCバランスだ。ここがいい加減だと、到底うまくいかない。
カロリー量はハリス・ベネディクト方程式から出される基礎代謝の1.5倍とかに設定すればよいだろう
そのうえで、低脂質ならP:30%, F:20%, C:50%のように割り振ろう。
たとえば1600kcal目標なら、P: 480kcal = 120g, F: 320kcal = 35g, C: 800kcal = 200g、といった感じだ。
この規約を守るためにも、あすげん/カロミルがあれば、計算が楽だったというわけだ。
プログラミングでは、実行時に行うと重すぎる計算はビルド時など事前に行ったりすることがある。
初代スーパーマリオブラザーズのジャンプは、1フレームごとに重力係数をかけて計算しているわけではなく、加速度がハードコードされている。
ブロック崩しでさえ物理演算するような現代においても、似たようなことをすることはある。
ダイエットで言えば、時間的余裕のあるタイミングで、できることをしておけということになる。
キャベツを千切りにしたり、きゅうりやトマトを切ったり、オートミールに材料混ぜておくことは事前にできることなのだ。
夜寝る前などにやっておき、明日の調理工数を最低限にしておくことが大事だ。
処理したものはジップロックコンテナにでも入れて、冷蔵庫にしまっておこう。
よく食べる鶏むね肉や牛もも肉なんかもキロ単位で大量買いして、1食量ごとに切り分け、ジップロックバッグに入れて冷凍庫に入れておこう。
適切なキャッシュがもたらす実行速度の向上効果は非常に大きい。
これは料理についても言える。
毎食ごとに献立を考え、材料を揃え、包丁で切ったり、コンロで焼いたり…などの調理を行うのは非常に非効率である。
いわば冷蔵庫はメモリキャッシュであり、冷凍庫はディスクキャッシュのようなものである。
よく1人分作るのも3人分作るのも変わらないよ〜などと言うが、同じ理屈で1食分作るのも、3食分作るのも、手間としてはたいして変わらない。
すでに広く使われ、実績のあるライブラリがあるのに、なぜ一から作らなければならないのか。
これはダイエットについても言える。
安価で大量に手に入るカット野菜などは、買ってしまえばいいのだ。
たとえばきんぴらごぼう。作ると面倒なきんぴらごぼうだけど、その面倒さの9割はごぼうを千切りするところにある。
千切りして水にさらし終わったら、きんぴらごぼうの調理工程の9割は終わっている。
しかもこの部分は、工数が量に依存しているため、大量作成の恩恵を受けづらい部分だ。O(n)である。
一方でカットごぼうを大量買いすれば、あとは炒めるだけなので量に依存せず、大量作成が容易になる。O(1)にすることができる。
他にも、オイコスヨーグルトとか、サラダチキンとか、Baseブレッドなどの外部サービスを使うのも良い。
プロジェクトの初期段階、リードエンジニアが重要なクラス群とサンプルとなるクラスをいくつか作った後は、それをひらすらに横展開していくことになる。
この段階では天才エンジニアなど必要なく、コピペマンでじゅうぶんになる。むしろ下手に独自の考えを持たず従順に開発してくれるぶん、そのほうが良いことさえある。
ダイエットについても同じことが言える。
なぜ毎食毎食、独自の健康メニューを考え出さないといけないのか。食事の都度、栄養成分を計算し、調整しなければならないのか。
あすけんで一度100点をとったらあとは、ひたすらそれをこすり続ければいいだろう。
朝
蒸しかぼちゃ
昼
ふかしたさつまいも
蒸しかぼちゃ
夜
りんご（皮ごと）
蒸しかぼちゃ
毎食似たようなものを食べていることがわかるだろう。
これは日単位でも同じで、別の日は牛もも肉が刺し身になったり、さつまいもが蕎麦になったりはするが、その程度の差だ。
どうしても違うものが食べたくなったら、そのときに改めて計算すれば良いのだ。
そうすれば手持ちのカードが増えていく。
インシデントが発生したとき、必要なのはリカバリーであって、そんな時に人を責めても何の役にも立たない。時間の無駄だし、士気も下がるだけだ
こうしたとき、自分を責めても仕方がない。自分をクビにはできないし、ダイエットは長期戦なのだ。
ある日に食べすぎたからと言って、次の日にその分を減らすと、必要な糖質や脂質が不足して代謝が落ちてしまったり、だるさが抜けなくなったりするため、そういう方向でのリカバリーはやめよう。
しっかりと痩せる食事スタイルが確立しているなら、それを続ければ良いだけだ。
どうせ1食程度ではそんなに太ることはできない。
計測は減量期間中だけでなく、むしろ減量終了後にこそ必要になる。
そもそも、減量前の食事が減量前の体重を作り上げてきたのだから、減量前の食事に戻せば、体重も戻るのは当然のこと。
もとの体重に戻りたくないなら、新たな食習慣を作り上げる必要がある。
プロダクトリリース後、つまり減量後の運用フェーズにうつったら、減量飯でもデブ飯でもない、心にも体にも良い食習慣へと移っていこう。
急激なUI変更がユーザーの反発を招くように、急激な食事変更は体重の反発（リバウンド）を招く。
そこで、オートミールだったところを玄米ごはんにするとか、ささみだったところを蒸し鶏にするとか、ちょっとずつ維持するためのご飯へと変えていき、どのくらいの量なら大丈夫なのかを見つつ、ソフトランディングしていこう。
おお、岡本太郎批判にそのまま使えそうだ。本来は万博会場全体の予算であったものを太陽の塔ひとつに使ってしまい、途中で発覚し慌てて止めようとしたが時すでに遅し。あの塔が完成した
[B! 万博] サクッと調べたので間違えてるかもしれんが 万博会場の建ぺい率は７０％な..
上記コメントは 太陽の塔内部の展示資料とパンフレットを読んだ私の記憶をもとに書いたのですが、改めて調べたところ
の間違いだと思います。いい加減なことを書いて申し訳ありません。ブコメも修正しておきます。
ただ太陽の塔建設は当時大変揉めていたこと、岡本太郎が勝手に暴走したことは事実のようです。
以下、参考になりそうなページをまとめておきます
会場計画プロデューサーの丹下健三氏と岡本太郎の取っ組み合いの喧嘩がさまざまな記事で言及されています。
中でも堺屋太一氏による「地上最大の行事 万博博覧会」は当事者による記述として興味深いので引用します
計画が出されたとき、万国博開催期間は梅雨の時期も含まれるため、人を集めるには「屋根」が必要だという意見が出た。しかし、これほど巨大な建造物の屋根をどのように作るのか、技術的な解決策は見えてこない。建設省や通産省からは安全性を危惧し、縮小変更を訴える声が強かった。
（中略： ここから大屋根建設の苦労が語られますが省略します）
お祭り広場の建築が軌道に乗り始めたと思った矢先のことだった。展示プロデューサーの岡本太郎氏が、お祭り広場の大屋根の真ん前に、塔をつくると言い出した。これが、かの「太陽の塔」である。
「すでにシンボルタワーは菊竹清訓氏が設計しています。あなたは展示プロデューサーなのだから、展示に集中してください」
菊竹氏が設計した蜂の巣状のシンボルタワーは、会場の南端に建てる予定で計画が進んでいた。しかし岡本氏は一歩も引かない。
「万国博の展示の中心には、一眼でわかるような造形が必要です。一番目立つ展示を私は考えました」と言ってスケッチブック４冊ほどを取り出した。そこには「太陽の塔」のスケッチが２００枚くらい描かれていた。（中略）岡本氏の熱弁を聞いたところで、もちろん丹下氏は納得しない。丹下氏の口調は次第に厳しくなり、
「お前にそんなものを造る権利はない」「造るとしても、目立つところにあるのは許さない」
どうしても造るなら、お祭り広場の屋根の設計を変更して、太陽の塔を屋根で囲って見えないようにする、とまで丹下氏は言った。
すると岡本太郎氏は烈火の如く怒り、関係者のいる前で2人は取っ組み合いの喧嘩を始めた。互いの弟子たちは喧嘩を止めるどころか加勢し、手のつけられない状態になった。慌てた私はいったん通産省が引き取りますと2人を制したが、「引き取るとはどういうことだ」と、今度は私が2人に罵倒される始末だった。結局、大屋根の中央に大きな丸い穴をあけて「太陽の塔」を突き抜けさせるという妥協案に落ち着くまでに１ヶ月かかった。
(「地上最大の行事 堺屋太一 万博博覧会」 p269~p280）
このように「太陽の塔」はもともとシンボルタワーとして造られたものではなかったが、結果的に二つのタワーが万国博に登場した。岡本太郎氏は「自分の太陽の塔と、菊竹氏のタワー、どちらが真のシンボルタワーかは大衆の審査に委ねるべきだ」という考えを示した。と同時に「自分には自信がある」ということを盛んに表明した。この勝負、岡本太郎氏に軍配が上がったことは歴史が証明している
なお、著者である界屋太一氏は通商産業(現経済産業)省の方であること、出版が2018年であることは注意が必要です。
まるで仲介役をしていたような書き方ですが、以下の小松左京氏の著書によれば通産省も強固に反対していたようです。
当初の見解とは大きく異なり太陽の塔が歴史的シンボルになってしまったせいで不都合なことはみんなちょっとずつ伏せている感じはありますね。
予算といえば、あの「エキスポの顔」といわれた高さ六十メートルの名物「太陽の塔」があやうく消えかかったことがある。テーマ展示の、総予算は前にもいったように建設費こみのあち見つもりで三十億は必要だと、岡本氏のスタッフははじき出していた。（この金額で理事会で説明する時、岡本氏はテーマ展示には「最低三十万円」必要だ、とやってしまった。石坂会長の「明治四十五年の万国博」とともに万国博の二大迷言とされている）
大蔵省筋はこの規模を内々に承認していたが、監督官庁の通産側は、あまり正面に大きなものを建てられると、ホストカントリーの日本政府館が目だたなくなる、という理由で強硬に反対した、テーマ展示の稔予算はせいぜい三、四億でいい、というのだ。モントリオールのテーマ予算百億と大変なひらきだ。そんな予算ではとてもテーマ展示はできないとプロデューサー側がいうと、もともとテーマなんてものは万風博にはいらないものだ、とまで極言した。
（中略）
予算の三倍にふくれ上った見つもりをむりやり削るのは大変な作業だった。業者サイドと一項目ずつ検討し、全体の仕様をかえ、やっと予算の倍ぐらいまで削った。だがそれをさらに半分にするのは、背筋の寒くなるような作業だった。
場合によっては、石を一つころがしておいても、これが「根源の世界」だとひらきなおってみせると豪語していたものの、当初のイメージが、はなはだしく萎縮してしまうのはさけられなかった。それに私は平野氏と話しあって、第三スペース「心の世界」に展示する、海外民俗資料収集のための、予算六千万円は、最初からおさえて、絶対手をつけないことにしていた。一・五倍にまできりつめる時、展示構想を基本からやりかえなければならないところにまできた。
テーマ展示に関わった小松左京氏が予算で苦労する様子が書かれています。現在の国立民族学博物館は小松左京氏と平野氏が守ったのですね。知りませんでした。
（id:ryotarox さんありがとう！）
id:tapi423 さん、こちらこそどうもありがとう。
よしウェブサービスを作るぞと意気込んだ。
まずCloudflare Workersが安いと聞いてるのでそれを使う。
ユーザー認証にはFirebase Authというのが良いらしい。
よし、使ってみるぞ。
えっ中国で使えないんですか？
プロキシサーバーを立てて回避？新規で選んだらアカンやつやん。日本人これ使ってるやつ多いよねぇ。だから世界で戦えないんじゃない？
さらに調べるとユーザーが増えるとコストが馬鹿みたいにかかるんですって。
なにゆってんの。日本人なら水と認証はタダじゃないと納得できない。
そういう事で、タダでできる認証を調べると、Luciaというのを見つけました。
Luciaはオープンソースの認証ライブラリ。ユーザー情報など置くDBは別途用意しなきゃいけないけどそれはしょうがないね。
あとセッションベースの認証だから安全性が高いんだって。すごいね。
ChatGPT「ユーザーセッションをDBに保存して、まだ有効期限をが切れてないかリクエストのたびにDBに聞きに行くやつや」
えっそれは・・・データベースへのアクセスがいっぱいになるよね？
ChatGPT「せやで」
あかんやん！DBのお金くらいは出したるとは言え、リクエスト毎のアクセスはあかんわ。
これもLuciaと同じくOSSだけど、Luciaと違ってトークンベース。
良いですね。私トークン大好き！
早速書いちゃうよー。ごりごりごりら。
ふう、いっぱい書いたね。もうApple、Google、GitHubの認証かけちゃった。
よし、これをスマホアプリでも使えるようにしないとね。Auth.jsとか大そうな名前のライブラリなんやから当然簡単にできるんやろなぁ。
・・・できん！え、嘘！？なんか同じ事聞いてるissueあるけど作者全然アプリに乗り気じゃない！って言うかクローズされとる！リバースエンジニアリングしたら余裕やお前らは作者様に迷惑かけるなボケとか言ってる奴もいる！
これはあかんわ・・・。そらなんとかしたらなんとかなるんやろうけど、「覚悟」がいるやん。暗闇の荒野に進むべき道を切り開く「覚悟」が。
だからアプリ開発者にもっと媚びるのが普通なのに、むしろ忌み嫌ってるフシさえある。
とりあえず今日はここまで。
明日はSupabase Authを見てみる。
そう、認証はタダでは無理だと分かったので。少なくとも命を削って良い機能じゃない。
でもSupabaseの無料枠はFirebaseの倍の量あって、課金入っても比較的安くて良さそう。
しかもCloudflare Workers が連携に公式対応！
正直それがどの程度のものか怪しいけど、見てみるで。
それにしてもサーバーサイドはつらいなぁ。
結婚式の披露宴のときに実際に流したけど、なかなかいいもんだった。
ゲーム中だと結婚式のイベントでずっと流れてるから、冒頭から流そうかと思ったけど、式場の人に「この曲はイメージとしては退場時の曲だからそっちの方が良い」と言われて退場時のときに流したぞ。
結婚式に結婚ワルツを流す人は結構いるみたいで、式場側のライブラリには普通にあった。N響版のやつだったかな。ルーラ版がいいとかコーラス版がいいとか言い出すと、自前で音源を用意する必要はあるけど、まあそこまではやらない。
他に結婚式に流せるようなゲームの曲はあるかと式場の人に聞くと、どうも式場側のライブラリにあるゲームの曲は2曲しかなくて、もう一つは確かFF8の「Eyes on me」だったはず。FF8に大して思い入れはなかったし、結婚ワルツ以外はバタフライとか、いかにも結婚式的な無難なチョイスで流したよ。
以下の記事、内容がひどくて空いた口が塞がらなかったのだが、
（はてブで）ブックマークして下手にホッテントリにでもなったら嫌だなと思いそっとブラウザのタブ閉じた。
が、しばらくすると残念ながらホッテントリ入りしてしまったので、はてブにコメントを軽く書こうとしたが100文字に収まらなかったので増田にした。
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
まず、「特定条件下では MySQL は我々のプロダクトには不向き」を「MySQLを使うと会社は潰れる」なんて表現するのおかしいでしょ。
以下の記事からの引用だが Uber のエンジニアは「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない、MySQL＋InnoDBに変えたら全部解決した」と主張している。
UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く
RDMS（に限らずライブラリやミドルウェア一般）の評価は採用する開発プロダクトの要件とユースケース次第。
Not for me/us. を「これを使うと会社が潰れる」って……MySQL開発チームから名誉毀損で訴えられろと思う次第。
(サーバサイド開発の言語は）TypeScriptでいい。と言いつつ、結論はこれ
| TypeScriptで書いたサーバーサイドのコードの半分ぐらいも属人化している。なぜかメンバーのキャッチアップが進まない。
ん？？？？
こんな評価眼で開発力で文章力の人を「厭味が無くて楽しめた」だの「公開してくれてありがとうございます」とか言うブクマカにもそれにスターをつける人にも衝撃だよ。
ちゃんと読んでくれよ。それから、ブックマークするか判断してほしい。あーあ
---
| 逆に、Uberエンジニアに対して、PostgreSQL開発チームから名誉毀損で訴えられろと思わないのは何故？
という言及への返信。
Uber に関しては。
自分たちが扱う規模のデータを捌ききれないという問題を、その原因が利用者（Uber）側ではなくデータ永続化におけるPostgreSQLのアーキテクチャが原因だと思われるということをきちんと測定して結論してるからかな？
さらにUberはそのことを安易に「PostgreSQLを使うと会社が潰れる」というような煽り口調の一般化をせずに自社には不向きだったということをブログに載せているため議論の土台が開けていることが重要だと思う。
今回の問題の記事はRLSとID採番というデータベースの根幹機能ではない付加機能で自分たちのプロダクトとミスマッチしているだけで一般化して罵ってるのが悪質だと思うんよなぁ
ミシンができて天職が機械に置き換わってしまった職人の嘆きをリアルタイムで聴いている感覚
といった感じで「歴史の証人になった気分がして良い」と言ったものの正直別に珍しいことではないんだけどね
人類は昔からそうやって機械化できることをどんどん機械化して楽できるようにして、それにより生まれたゆとりを新たな価値創出に費やしてきたのだから
誰かのせいで仕事をつまらなくさせられたと思っているそこのあなただって誰かの仕事をつまらなくさせた側の人なんですよ
あなたが書いたプログラムだってまともなCPUがない時代は回路設計者がえいこらえいこら論理回路を一つ一つブロックのように組み合わせて実装していた
ただの電卓作るのに死ぬほど時間をかけて回路組んで、トランジスタレベルからめちゃくちゃ設計して、それが開発だ！楽しいんだ！って言っていたのかもしれない
その人にとってはアセンブリ言語でホニャララと書くだけで計算結果が出てきてしまう世の中つまらねぇと思っていたかもしれない
更に行ってしまえばアセンブリ言語でホニャララとかける人にとってC言語もそういう存在かもしれない
それが世の中の常であり、進歩なんだよ
と書いてて途中で気付いたが、ITにだけその進歩が辛い側面はあるのかもしれない
ミシンが普及して職人が服を作らなくても良くなっても、腕の良い職人が作る服には工芸品の"味"という価値が残ったと思う
他にも自動車が生まれても趣味としての乗馬は残ったし進歩により旧世代の遺物になったとしても何かしらの価値が残ることが今までは多かったはず
一方、ITはAIが発達し品質も高く速度も出るようなコードが書けるようになったら手書きのコードに何の価値もなくなってしまう
誰かすげー奴がすげーライブラリを無償で提供しちまったら同じ機能を実装する価値がなくなってしまう
手書きのコードから生まれるプロダクトに手書き特有の"味"は生まれない
でかい会社で1から作るものだったのがツールとかライブラリが整備されて1から作らなくても良くなったのがつまらないのでは？
今まで汗かいて必死こいて実装してきたものが、このライブラリ使えばパッとできちゃいますってなってるのが自分たちの存在意義を否定された感じがしてつまらないってことだと思う
UnityもUnrealEngineも本格開発するなら大差はないんですけどね。
どのみちカスタマイズしないといけないというだけで、より短縮できるエンジンを選択しただけの内容ですよ。
が評価ポイントになりますが、ゲームによって不必要なものは削除したり先鋭化したりしますが、大元の開発者（UnityやEpic Games）との連携が不可欠になってしまいます。
大体の場合は海外はレスポンス非常に悪いので、自社でやれるなら自社でやったほうがカスタマイズしやすいし、何なら最新の描画処理なんていらない、ってなるんです。
もちろんUnity最高HDRPいいよね、とかはちょっと……となりますが、エンジンの性質を知ってる人であれば別にUnityだろうとUnrealEngineだろうと大差ないです。
スタンダードの状態での品質はもちろん大型タイトル作るならUnityは論外ですが、小規模〜中規模で制作するならUEだとBP管理がクソ面倒なので、Unityの方が良いです。
初代バイオハザードがアローンインザダークに影響されたというのはカプコンから出てた有名な話だと思うけど
あと、大手はゲームエンジン維持するコストが許されるんだけど、
ゲームエンジン作ってるのはカプコン本社側で、実際のゲーム開発は末端に丸投げだったりもするんで、
仮に本社側のゲームエンジンにバグがある、それこそゴミだった、としても逆らえないし、トラブルになりがち
システム内製するのと同じ
下手に自社フレームワーク作るぐらいなら、RailsとかLaravel使った方が良かったのに、みたいな話、
Webでもありがちだと思うんだよね
実際、カプコンでそんな話で揉めてるような噂はあったはずだけど、あくまで噂なんで、
信じるか信じないかはあなた次第なんだけど
ライブラリやフレームワーク、ゲームエンジンはどれだけ鍛えられてるか、というのが大事なので、
鍛えの度合いだったら、企業内製のエンジンよりUnityやUnrealの方が全世界のユーザーに鍛えられてるわけで、
大手はそれでも内製できる余裕があるのかもしれんけど、どこもそうではないだろうし、
内製システムってあらゆる分野で揉めがちだよ、社内政治まで関係したりもする
そんなのよりオープンなものを使えよ、みたいな流れってあると思う
TRONは外圧で潰されたとか、日本ってやっぱ駄目だよねみたいな話はウソであって、
孫氏の苦言が一番的確で正しかったと思うんだよな
で、ゲームエンジンもAIも、あらゆる産業に相似の現象が見られると言いたかったわけだ
普遍的な話をしたんだよ
https://b.hatena.ne.jp/entry/s/zenn.dev/cybozu_frontend/articles/7733bf0560829e
フリーランスでゲームエンジン担当したり調整したりの仕事を今でもやってます。
「ITがつまらなくなった」「ゲーム制作がつまらなくなった」のは違う角度の話も入りますが同意です。
おそらく現在４０歳あたり以降の人たちは「めちゃくちゃコード書けた時代」の人たちだったと思います。
私もめちゃくちゃコード書いてましたし、他人のコードも修正してたし（それでキレられたり１日中討論したりも）、何より車輪の再発明がすごく楽しかった。
Game Programming Gemsが唯一の経験者のナレッジの詰め合わせで、貪るように読んでましたね。懐かしい。
というよりそうでないと生き残れなかった。
何よりもコードを書くのが楽しい、起きてる間は全てコーディング、アーキテクト、新技術の調査に時間を充てるような生き方しか出来ない人たち。
生産性？それよりもテンプレートプログラミング面白くね？意味あるか分からんけど。そういやこのコンパイラいいよね、メモリの使い方上手くてさあ。
プログラミング全般の技術力は、正しい知識を身に着けているかも重要なんですが、それよりも重要なのはライブラリの仕様を覚えるくらい何度も何度もアウトプットすることなんですよね。
DirectXやOpenGLの仕様を追えばだいたい効率的な計算方法や描画手法は身についちゃうので。
技術体系に紐づくものだったり、デザパタとかある程度知っておくものもあるにはありますが、何なら自分で見つけたくらいの方が遥かに理解度が高い。
頭で創るより、実際に書いてコンパイラ通して目で確認するほうが何倍も重要。
3Dゲームの知見がまだまだ日本に足りていない時代、ドラマチックな演出を行おうとしたら別の技術が必要になった。
今の時代では、ただFPS/TPSにすりゃええって回答になっていますが、模範解答として映画しかモデルが無かったんですよね。
しかも日本の画作りは時間を使った画作りより、止め画、見栄を軸とした画が多くて、海外のセンスとはジャンルが違う。
最先端の技術を生業にしていた大手ゲームパブリッシャー、デベロッパーは頭を抱えていました。
なにせ、個人の技術で戦ってきてしまっていた日本では太刀打ちできないことがわかったからです。
すでに海外では映画や映像の最先端の技術者やクリエイターをかき集め、サイエンスとしてナレッジ化を進めていました。
物理学者を集めまくってたのもそのときだったのを覚えています。
結果的に、大手は各社最高のグラフィックエンジンやクロスコンパイルエンジンを自社開発しようとして、（ほぼ）全て断念していますね。
……ただフォローのつもりで言いたいのですが、失敗ではあったと思いますが、そこで得た技術は非常に重要なものでして
日本は失敗を許容しない組織が多く、初めるのが遅く、辞めるのも遅い、それでいて二度と挑戦させない文化なので育つ土壌が無いんだと思います。
だいたい誰かが俺仕様で作ったクソみたいなコードを修正して、高速化したりメモリリーク改善したりがメインです。
「またコレか…」のパターン多すぎる。これがつまらなくなった所以です。
GCの仕様くらい考えたらなんでスパイクが起こるかわかるやろ……なんで調べんのなんて思うこともあります。
ただ出来ない人が多い、才能の無い人がビジネスだけでゲーム作ってる時代でもあるので、そのおかげでおまんま食べられてるんだよなって考えてます。
プロジェクトが破綻してることも多くて、その大部分はエンジニアがクソすぎるってのが多いですね。
体制の問題もあるにはあるんですが、ゲームにこだわることもなく、ただ稼げるで来ちゃった人たち。
だからそんな人達に何か伝えても響くことも無いし、生き方も違うので何も言わない。
ゲーム自体もどこかで見た何か。なので正解が存在するのでアーキテクトや制作に頭をひねる必要も無い。
感謝されるのでやりがいはあるんですが、当時激論を交わしていたような人たちはゲーム業界から離れ超ホワイトな外資系や大手でぬくぬくやってます。
幸いなことにソーシャルゲームバブルが起こり、その波に乗れた人たちです。
たまたま私の周りはコミュニケーション能力や問題解決能力、分解能力が高かったのでちゃんと地位を築き、ちゃんと生活しています。
ChatGPTさんによる要約
この記事は、ゲーム開発業界の変遷についての筆者の考えを述べています。以下に要約します。 かつてゲーム開発は、職人芸的な要素が強く、リードプログラマーが中心となり、物理エンジンや数学ライブラリを自作することが求められていました。しかし、UnityやUnrealのようなゲームエンジンの普及により、こうした職人技は無意味に近いものとなり、開発者はゲームエンジンを使いこなすスキルが求められるようになりました。その結果、コードをゼロから書く職人的な仕事は減り、ゲーム開発はコンテンツ制作に近い作業へと変わりました。 また、筆者は、ゲーム開発やIT業界において、老害的な態度や若い世代をバカにすることの問題についても言及しています。新しい技術や若い世代の感性を受け入れ、彼らから学ぶ姿勢が重要であると述べています。 要するに、ゲーム開発がかつての職人芸から標準化されたエンジンを使った作業に変わり、これに適応できない人々の不満や葛藤を描きつつ、新しい世代との関わり方について考察しています。
