逆説的になるけど「ChatGPTに聞いただけのことを貼ってくるやつ増えたよね。うんざり」という話題が増えてきていることそれ自体が、今のアプローチの延長線上にあるものがそのまま流行るし性能も改善されるであろうことを示してるように思う。
「すごーい」で終わってたら逆に悪い兆候。
なんか最近また「心理的安全性」の意味を履き違えてるやつが増えてきてる印象
元々この言葉誤解が多いから嫌いなんですけど、「心理的安全性」って
「お互いに笑って殴り合える環境」
であって
「私が気持ちいいようになんでも察してくれる環境」
ではないからな？？
以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。
今回はその後としてのお話になります。
現在はサービス自体にページ表示速度等のパフォーマンスや運用費等の問題が山積みでリリース後開発が停止しています。
このままフェードアウトするのは勿体無いなと思い今回ソースコードを無料公開する事にしました！
最近は個人開発ネタが流行ってる事もあって少しでも話題になって多くの方の目に触れて、改善案やサービスの方向性について意見交換して開発のモチベーションアップに繋がると嬉しいなというのが個人的な狙いです。
今のLaravelが如何にダメで時代遅れか
どこかに書き並べていきたいが…
Octaneとか関係なく、そもそもの設計の話で、Laravelのドキュメントに翻弄されてメンテ不能になってる会社が多過ぎる。
Laravelによる経済的ダメージは計り知れない…
とりあえずアウトラインだけ
・本番デプロイ方法が非公開
・あるべきアーキテクチャ
・何でも出来るORMがModel
・標準で関数セット置場が定まっておらず、テストがHTTP形式になる
・apiルートのオプション化
・OSSは収益化できてナンボ
・OSSと様々な思惑
基本の考え方としては「触らなくていいコード」を目指した実装にすること。
コントローラーに入ってくる$Requestからそのまま入力を取り出してORMでゴニョゴニョするのはNGで、そこはプレゼンテーション層だと言う意識を持つこと。
Laravelの中がプレゼンテーション層なのであれば、つまり他に定まったインターフェース（SDK）が必要と言うこと。
そこから目を逸らさせて「これ一本で何でも出来る強強フレームワーク」を名乗るのは悪なんですよ。
結果どこもかしこも密結合だらけ。
ここで今思ってること並べても伝わる気がしないけど、最終的にはただのHTTPルーターからSDKに橋渡しするだけの構成が1番シンプルで負債化しにくいと思う。
Eloquent ORMの代替で有名なのが出るだけでLaravelは終わる。
ORM界隈もGQLに寄ったり混沌としてるし、なんなら生SQLで良いまである。
生SQLは良いですよ。
ワイがHello worldやってた時代に書いたSQLがまだ使えるんですもの。
寿命の長い言語は良いですよ。
PHP、Composerのコンビとか極悪過ぎる。
あ、そうそう。
lumenはサ終しました。
Octaneが出来たので今後は全部Laravelでやってくれとのこと。
設定周りもう少し強化してくれてたらlumen一択の世界線もあったのに…
ほんと考えが全く合わない。
補足
ORMをあの位置でモデルとするには何でも出来すぎるんですよ。
テーブルがどう操作されてるか把握するには全てのコントローラーメソッドを追わないといけない。
非公式でリポジトリパターンとかありますが、それこそがモデルであって、ORMはその下のレイヤーに位置しないと危険なんです。
結論として、Laravelの立ち位置はWordPressを卒業した人の最初のステップにフィットしたものになってる。
（ここで大衆のイメージとかけ離れてる）
だからオンプレ前提だし、SSR推しだし（MVC）、画面とサービスのインターフェースをごちゃ混ぜにしてる。
これで大きなもの組もうとすると失敗する。
マイクロサービスが必要なレベルになると建て付けの階層が浅過ぎて崩壊するんです。
個人的には真顔でそうなって欲しいと思ってます。だって、能力主義自体が生まれ育ちによる差を前提にした差別的な思想であると思うので（極論ですが）。
それに、自分たちだって過去にそういう人たちを踏みにじった結果今があるのに自分だけは……というのは受け入れづらいので。
「努力して身につけた技術が、万人に扱える陳腐なものになってしまってもいい」
「築き上げてきた努力が、全て誰かのものになって自分に還元されなくてもいい」
「他の誰かのためになったのなら、功績が全て無価値なものと棄てられてもいい」
↑これ真顔で言えるの怖ぇって
プログラマ不要論を煽るつもりはないけど、ここ最近での進化を踏まえると、数年後には現在とはプログラミングのありかた自体が大幅に変わる覚悟はした方がいいのは確かだと確信してる。
といっても、どう変わるかは読めないけど。
平素より、当社が運営するデリバリーサービス「出前館」をご利用いただきまして、誠にありがとうございます。
2024年10月26日（土）14時30分頃よりサービスを停止しておりましたが、先ほど再開いたしましたのでお知らせいたします。お客さま、加盟店さま、配達員さま及び関係するすべての皆さまに、多大なるご不便とご迷惑をおかけしましたことを深くお詫び申し上げます。
なお、本事案に関する詳細は次のとおりです。
10月25日（金）20時頃、サーバが高負荷となったことからサービスを停止し、当該サーバより切り離してサービスを再開いたしました。原因の調査を継続していたところ、翌10月26日（土）14時30分頃、前日とは異なるサーバが高負荷となり再度サービスを停止したのち、暗号資産マイニングマルウェアである通称「RedTail」に感染したことが発見され、当該マルウェアの削除を実施しました。サービスの再開にあたってはさらに万全を期するため作業を慎重に行ったことから想定よりも時間を要してしまいましたが、安全性が確認できたことからサービスを再開いたしました。なお現時点において個人情報の流出についてその恐れはありません。今後新しい事象が判明した場合は、速やかにお知らせいたします。
再発防止と、より良いサービスの提供に努めてまいりますので、変わらぬご愛顧のほど、よろしくお願い申し上げます。
ビジネスの現場で、「ゆるふわ提案」と呼べるような曖昧なコミュニケーションがしばしば見受けられる。これは単に選択肢を並べるだけの提案や、メリット・デメリットを羅列するだけの説明のことを指す。
X（旧Twitter）が開発者向けAPIの利用料金を2倍に値上げすることを発表し、個人開発者の間で激震が走っている。
これはXの開発者向けフォーラムで告知されたもの。有料プランの中ではローエンドなBasicプランにおいて、これまで月額100ドルだった基本料金が、2倍の200ドルへと値上げされる（Proプランの基本料金は月額5000ドルで変更なし）。開発者向けAPIの有料プランはイーロン・マスク氏による買収後のときにも制限が厳しくなり、当時、サービス継続を断念した開発者も出た経緯がある。今回は上げ幅も大きく、前回はなんとか費用を工面した個人開発者も今回は耐えられなくなる可能性もあり、それゆえ波紋を呼んでいるというのが現在の状況だ。なお、気象警報、交通更新情報、緊急通知を投稿する認証済みサービスについては、引き続き無料で利用できるとしている。
「エンジニアが健康でどうすんの？」みたいな話をする人がいて
どういう意味か聞いてみたら仕事頑張ってるかどうかの基準が不健康か否かみたいな返答だった。
そういうよくわからない価値観の人ってまだいるんだなと勉強になった。
※冗談だとしてもあまりおもしろくない
健康面を軽視して仕事が続けられなかったら本末転倒だろってのがワイの答えなんだけど、なんか変なこと言ったかな？？
データベース企業が典型だけど、データを持てる会社というのは大きくなっていく。反対にデータ連携やデータ統合みたいなデータが通るだけの土管の会社はあまり大きくならない。これはなんでなのか考え出すと割と不思議だけど、「データの重力」という概念として知られている。
「UNIXという考え方」悪い本というわけではないが、話半分に聞いておいた方がいいところもある。特に移植性のところ。おそらくUNIXのオリジナル開発者の結論はシェルスクリプトではなくGoなのではないか。……という話を日曜の朝にしました。
主キー設計では、「自然キー vs サロゲートキー」や「連番 vs 乱数」が主題になることが多いですが、今回はカラムサイズに注目して、主キーのサイズが検索性能に与える影響について調査してみたいと思います。
インデックスを使った検索が高速であることはRDBの常識中の常識ですが、その時もディスクやメモリからインデックスの値を読み取ってCPUを使って比較を行う操作が発生するわけで、値のサイズが小さいことは理屈上ではCPUキャッシュの利用やその他IO処理などにおいて有利に働くはずです。
今回は主キーを指定した単体取得のクエリにおいて、その影響がどの程度なのかを実際に計測して確認してみたいと思います。
[...]文字列型同士の比較では主キーのサイズと検索速度にきれいな相関が見られますが、異なる型の間では主キーサイズは検索速度の大きな決定要因にはならないようです。
特に int_table の検索が想像よりもずっと遅く、long_table よりも int_str_table よりも遅くなっています。 int_str_table の結果は主キーのサイズがより小さい long_table の結果よりも早いので、文字列比較が早くなる原因 (or 数値比較が遅くなる原因) が何かしら存在していそうです。
ただ、UUIDに限って言えば、「UUIDを文字列型で保存すると速度的に不利」という言説は、顕著な違いが確認できました。
「主キーのカラムサイズが大きいほど検索性能が下がる」という常識的な仮説は、実際に計測してみたら、異なる型の間では成立しませんでした。
「推測するな、計測せよ」という格言の大切さを実感させられます。
ただ、クエリの実行速度はRDBMSの実装だけではなくCPUアーキテクチャなどにも依存しているはずなので、クラウドサービス上などの別の環境で計測したら別の結果が出るかもしれません。
例えば、1つの比較実験として同じ環境で shared_buffer のサイズを最小値の128kBまで下げた状態でも計測を実行してみましたが、テーブルごとの傾向も実際の計測時間も大きな変化は見られませんでした。
無駄なミーティングは減らすべきという考えには完全に同意しつつ、自分はミーティングを先にセットしてしまって事前にアジェンダを作りながら考えや論点を整理して進めることも多い。締切駆動の派生、"ミーティングアジェンダ駆動"で整理していると言える。
自分にとっては素早く物事を前に進める"型"のひとつになっているので、どんなアジェンダdocsをまとめながら整理しているか雑に書いておく。
・目的
・今日のゴール
・参加者と役割
・注意点
・たたき台
・Appendix
Lllama-8B構造で学習された最初のBitNetであり、全てを変えてしまうゲームチェンジャーでもある。CPUのみで秒間5-20トークンを出力する。超強力なLLM推論エンジンの出現だ。
BitNetとは、そもそも1.58ビットに相当する情報量で、本来は4ビット以上必要な大規模言語モデルの計算を劇的に高速化する技術である。
LLMの推論には通常は巨大な浮動小数点数(8ビットから16ビット)の、大量の乗算(掛け算)が必要なため、GPUなどの特殊な半導体を必要としていた。特にNVIDIAのGPUがこの目的にマッチしていたので今も世界中で争奪戦が行われている。
しかし、BitNetは、そうした複雑で大規模な計算を、単なる足し算と引き算に変えてしまうという大胆な発想で、モデルの推論を劇的に高速化し、しかも計算コストの高い乗算を完全に排除できるという夢の方式としてなり物入りで登場したが、実用性は全くなかった。
ところがついに実用的なBitNetが登場した。それがBitNet-Llamaである。
WordPressの創始者であるマット・マレンウェッグ氏が、WordPress特化のホスティングサービスである「WP Engine」を痛烈に批判し、WP Engineからのアクセスをブロックしています。この問題に続き、WordPressのマレンウェッグ氏が、WP Engine保有の超有名プラグイン「Advanced Custom Fields(ACF)」をフォークしたと発表しました。
開発チームは「マレンウェッグ氏の行動は非常に懸念すべきものであり、WordPressエコシステム全体をひっくり返し、回復不能な損害を与える重大なリスクがあります。我々や他の多くのプラグイン開発者およびコントリビューターが、プラグインを皆で共有するという精神のもと運用してきたこのオープンプラットフォームを、マレンウェッグ氏は一方的にコントロールしようとしています。彼の試みは深刻な信頼の悪用、多様な利益相反、そしてコミュニティにおけるオープン性と誠実性の約束を反故にするものです」と述べ、マレンウェッグ氏を批判しました。
ACFからの批判に対して、WordPressは「このような事態は過去にも何度か行われており、ディレクトリに参加することで同意することになるガイドラインに沿った行為です。あなたのバージョンの成功をお祈りします。我々は入手可能な最高のGPLコードを使用して、ユーザーにとって素晴らしいバージョンを作成できることを楽しみにしています」と述べ、ガイドラインに沿った正当なフォークであると主張しています。
なお、WordPressによるWP EngineからのアクセスブロックおよびACFの一方的なフォークを、BasecampやHEYの開発者であるデビッド・ハイネマイヤー・ハンソン氏は、「MetaがMicrosoft(GutHubとnpmの所有者)と法廷闘争を起こしたところ、MicrosoftがGitHubからMetaの従業員が使用しているリポジトリへのアクセスを全面禁止し、MetaのReactリポジトリを乗っ取って自社プロジェクトにフォークするようなものです」と説明しました。さらに、「オープンソースコードレジストリを武器にすることは決して許されることではなく、レジストリは中立的な領域のままでなければいけない」と述べ、この問題はWordPressとWP Engineだけの問題ではなく、オープンソースプロジェクト全体に影響を与え得るものであると主張しました。
ハンソン氏の主張に対し、マレンウェッグ氏は「ハンソン氏はオープンソースの専門家であると主張していますが、彼の有害な性格とチームをスケールさせる能力の欠如により、彼は約5兆ドル(約750兆円)相当の優れたアイデアを発明したにもかかわらず、その価値の大部分が他の人に奪われてしまいました」と主張。さらに、「ハンソン氏のような賢い人が、WP Engineのつまらない手法に騙され、商標ではなく『GPLコード』やフォークの問題に話を逸らしてしまうことは驚きです」と語りました。
これに対して、ハンソン氏は「Shopify、GitHub、Gusto、Zendesk、Instacart、Procore、Doximity、Coinbaseなどの企業がRailsを使って数十億ドル(数千億円)の評価額を獲得したと言われることを、私は誇らしく思います。過去20年間、進化と保守を続けてきたウェブアプリケーションフレームワークでこれほどの価値が生み出されたのを見ることは、この上ない満足感です。生涯の仕事が実現したかのようで、素晴らしい勲章であると言えます」と述べ、自身のこれまでの仕事に悔いはないとしました。
なお、ソフトウェア開発者のGavin Anderegg氏も、「人気のプラグインを一方的に乗っ取るというのは狂気の沙汰であり、サプライチェーン攻撃とどう違うのか私にはわかりません」「そもそも、乗っ取りの原因を作ったのはWP EngineからのアクセスをブロックしたWordPress.org自身です。WordPressはたまたまACFに軽度の脆弱(ぜいじゃく)性を発見し、ACFはWordPressからアクセスをブロックされているためプラグインをアップデートすることができません。これを理由に、WordPressはACFプラグインを乗っ取ろうとしているのです」と述べました。
米AppleのAI研究者らは10月7日（現地時間）、「GSM-Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models」（LLMにおける数学的推論の限界を理解する）という論文を発表した。
この論文は、LLM（大規模言語モデル）が、本当に人間のように論理的に考えて問題を解けるのか、という疑問を検証している。結論としては、LLMは今のところ、表面的なパターンを真似て答えを出しているだけで、真の推論能力は持っていないと主張している。
研究者らは、これらの問題点を検証するために、「GSM-Symbolic」という新しいテスト方法を開発した。これは、LLMの数学的推論能力を評価するためのベンチマークデータセット「GSM8K」を改良し、問題の表現や数字を柔軟に変えられるようにしたもの。また、「GSM-NoOp」という、無関係な情報を含んだ問題集も作成し、LLMの推論能力を評価した。
実験の結果、OpenAIのGPT-4oやo1-previewなどのLLMは、他のLLMと比べて高い性能を示したが、それでもGSM-NoOpのような引っ掛け問題には弱く、真の推論能力を獲得するにはまだ課題があるとしている。
研究者らは、LLMの限界を克服できるかどうかについては明言していない。現在のLLMが真の数学的推論能力を獲得するには、パターン認識を超えた、より高度な推論能力の開発が必要であると結論付けている。特に、問題の本質を理解し、無関係な情報を適切に処理できる能力の向上が不可欠であると指摘する。
まとめると、わたしは周りと同程度の仕事をこなせるようになったり、自分に強みが生まれて頼られたりした結果、一人前になったと感じたようです。みなさんも、まずは「チーム全員が最低限できること」をできるようになり、かつ、「チームの誰よりも強いところを作る」ところを目指して、「そうなるにはどうすれば」と考え、必死にくらいついていくのがいいかなと個人的には思います。3年経ったら自動的に仕事するようになるわけではありません。3年後にどうなっていたいか考えて、それに向かって日々行動するのです。
bluemonday は、Go で実装された HTML サニタイザーです。高速で、高度に構成可能です。
bluemonday は、信頼できないユーザー生成コンテンツを入力として受け取り、承認された HTML 要素と属性の許可リストに照らしてサニタイズされた HTML を返すので、コンテンツを Web ページに安全に含めることができます。
ユーザー生成コンテンツを受け入れ、サーバーで Go を使用する場合は、bluemonday が必要です。
分かりやすく説明すると、GaudiはGPUから、普通のGPUに求められるグラフィックス機能を省いたものだ。言うなれば「ガチのGPGPU専用GPU」なのだ。
「NVIDIA Hシリーズ」や「AMD Instinctシリーズ」といった競合製品は“GPU”で、3Dグラフィックスのレンダリングにも対応している（実際に、クラウドゲーミングや超高度な3Dグラフィックスを扱うサーバでのレンダリング用途で採用されるケースもある）。そういう意味で、ある程度の汎用（はんよう）性も備えている。
それに対して、Gaudiシリーズにはグラフィックス機能が一切搭載されていないため、HシリーズやInstinctシリーズのようにレンダリング用途には使えない。極端な言い方をすれば超高速な演算をすることにしか、役割を見いだせない。
普通のGPUとしては利用できないので、「AIアクセラレーター」と呼んでいる――そう解釈してもいいかもしれない。
近年、IntelはAIにとても注力している。しかし、圧倒的なリーダーシップを誇るCPU事業と比較すると、正直いってブランド力は弱い。
昨今のAIは、GPGPU的なアプローチで進化してきた。Intelは「GPGPU製品の投入」という“初手”でつまずいたため、このブームに何としても応えられる製品（プロセッサ）の投入が急務かつ不可欠だった。
そこで同社は、自社でのGPGPU製品の開発は諦め、“一点突破”型のAIアクセラレーターとしてのGaudiシリーズを会社（Habana Labs）ごと手に入れ、それを強化していく方針を立てた。
繰り返しの説明となるが、GaudiシリーズはAI開発における「学習」、そしてAI活用時の「推論」の各フェーズにおいて強力な性能を発揮する一方、GPGPUサーバとしてのポテンシャルは持たない。この“一点突破”な特質が、市場やユーザーにどう受け止められるか――ここにGaudiシリーズの成否がかかっている。
今後Gaudiシリーズが成功を収めるには、速やかに大口の顧客を確保し、それを逃さぬようより性能強化された新型を継続的に市場投入し続けることが重要となるだろう。Xeon Phiコプロセッサのように「5年で終了」では、たまったものじゃない。
■ はじめに
本記事の内容は数年前の状況で、現在は修繕されている可能性があります。
また、入社希望者を止めたり、Cygamesの各ゲームタイトルへのイメージを下げる目的はございません。
Cygamesは企業イメージを落とさないよう社員による内部情報の漏洩やSNS投稿等にかなり厳しく網を張っています。
特定されたらどうなるのかが怖くて、離職から数年間は何もせずただCygamesのCMを目にする度に軽いPTSDを発症していました。
現在、労働中に患った軽度な精神疾患が元となり精神障害へと発展した為、本記事を書こうと決めました。
■ 最初の部署でのセクハラ行為
私は開発エンジニアとして所属しました。
まず初めに所属した部署で、上長からセクハラ行為を受けました。
- 懇親会で使うお店の下見をしたいと言って2人きりで飲食させられました。
→その時私は所属から1週間程度だった為、断ることが出来ませんでした。
- その後も飲み会に誘われると何故か2人きりだったり、その場で「つい最近まで私と同じ年頃の女性と不倫していた」という話をされました。
- 泥酔した上長から「俺、お前の事が可愛くて堪らないんだよ」と言われました。
- 年末年始休暇中にプライベートな内容のLINEを送られました。
→部署内のLINEグループがあるとのことで所属して直ぐにLINEを登録していました。
- 飲み会の翌日朝、私の個人LINEに「昨日は楽しかったね。飲みすぎちゃったから、今日はサボっちゃうね」と送られ、その後送信取消をされました。
- 色々な飲み会に誘われ、中には下ネタばかり話している会もありました。
これらを人事に相談したところ、私が別の部署へ異動となりました。
■ 他部署のマネージャーからのセクハラとパワハラ行為
- 開発スケジュールの相談をしに行った際、「私の部署の上長と話がついてるから」と言い、取り合ってくれませんでした。
- 私の呼び掛けを無視し、会議で私がまるで居ないように会話していました。
- 高圧的な態度を何度も取られ、私が耐えきれずその場で泣いてしまうこともありました。
- 懇親会の後、空がまだ明るかったので、「ラブホ行って朝帰りしたみたいだな」と私の方を見ながら発言しました。
これらを人事に相談したところ、この方は降格処分となりました。
→私の他にも複数人から訴えがあったようです。
■ 異動後の部署でのパワハラとモラハラ行為
- 全体朝礼の場で、PMが、特定の個人が過去に起こした過ちを何度もネタにして馬鹿にしていました。
- リリースされた箇所に実装ミスが発覚した際、PMがエンジニアリーダーに対して「原因が分かるまで帰るな」と命令し、リーダーを含め複数人が徹夜をしていました。
翌朝出社した際、まだ原因が解明出来ておらず、疲弊しきったリーダーが謝罪していました。
- リリースされた箇所に実装ミスが発覚した際、PMがエンジニアリーダーに対して「誰が実装したんだよ？そいつがこのバグのせいで損失した金を払ってくれるんだろうな？」とエンジニア全員に聞こえるほどの大声で叱責していました。
→私はこの時の怒声を今でも鮮明に覚えており、若干のトラウマとなっています。自身がリリースする際にかなりのストレスを感じていました。
- エンジニアリーダーはその後体調不良で遅刻や欠席をされることが多くなりました。
- 労働時間外の深夜や休日でも、不具合が発生した場合すぐに修正しないといけない為、夜眠ることが怖くなったり、休日も落ち着いて心を休めることが出来ませんでした。
→エンジニアリーダーと食事をした際、リーダーは会話中でもApplewatchに通知が来る度すぐに開いて確認しており、常に緊張状態にあるようでした。
- プランナーリーダーと機能実装の相談をする際、私を小馬鹿にしているように鼻で笑ったり、強い口調で常に威圧的な態度を取られました。
→私はこれをきっかけに一過性の鬱状態となり、その方と話した後にトイレで嘔吐したり、一時他人と話すことが出来なくなり、別室で作業をするようになりました。
その後、そのプランナーリーダーと関わらない部分の実装を担当するようになりましたが、鬱状態が治らず、限界がきて離職する運びとなりました。
■ その他
- エンジニアマネージャーは一日中YouTubeで釣り動画を見ていました。
- 社内部活があり、私はダーツ部に入部したのですが、テキーラを何十杯と煽られ急性アルコール中毒になり入院しました。
■ 最後に
今や他社のゲームも盛り上がっておりあまり目立たなくなりましたが、一時期はウマ娘やゾンビランドサガ、グラブル等の広告や話題が街中・TVCM・SNS等で目にすることが多かった為、その度にフラッシュバックして嫌な気持ちになる事が多かったです。(現在進行形)
このせいで佐賀県に個人的な苦手意識が芽生え、大好きなお笑いのキングオブコントでスポンサーとなった時はショックを受けました。
以上がCygamesでの労働体験のうち黒い部分です。
1人でも多くの人が幸せな環境で働けること、またブラックな労働で壊れてしまった心が治りますようお祈りしています。
IT企業というかSES企業あるある
- 例外とコンパイルエラーの区別がついていないJavaプログラマー3年目
- コードを変更したことで失敗するようになったテストコードは全て削除してしまうITエンジニア3年目
- 失敗するテストコードのassertionを全てコメントアウトしてテスト成功したことにするITエンジニア4年目
- コードレビューでロジックの誤りを大量に指摘されると泣きながらパワハラ相談室に通報するITエンジニア5年目
- コンパイルエラーがあるままコードレビューを依頼する癖が何年経っても治らないITエンジニア7年目
- スタックトレースの内容を読まずに「謎のエラーが発生した！」と一日中騒いでるITエンジニア20年目
- データモデルの正規化ができないベテランITエンジニア
- 基本情報に10年間落ち続けて結局あきらめたベテランITエンジニア
- ChatGPTのハルシネーションした回答をそのまま客先に提案し続けて案件を失注するベテランITエンジニア
- 公式ドキュメントよりもChatGPTを信用しているベテランITエンジニア
- フリーランスの外国人よりも日本語が使えない日本人（日本語以外の自然言語を扱えるわけでもないし人並みにできることが他にあるわけでもない）
- ここまでに書いたようなレベルのITエンジニアが社員の半数以上を占める
- プログラミング言語の入門書の内容を半分以上理解しているメンバーが0人の開発チーム
- ほとんど意味の無いテストしか設計できず、1年かけてテストしたのにリリースから1ヶ月で不具合が3桁報告されるシステム
- 客先常駐しすぎて客の立場でしかモノを言わなくなった取締役
- 新卒1年目の社員を1人で客先常駐
- 4次請メンバーを2次請に1人で客先常駐
- フリーランスを自社の社員と偽って客先常駐
こんなレベルの会社でも倒産しないのでSESは本当にすごい
スクリプト言語「Python」の新しい年次リリース「Python 3.13」が、10月7日に正式リリースされた。多くの新機能と最適化が含まれている。
「Python 3.13」では、「PyPy」ベースの新しい改良型インタラクティブインタプリターを搭載。複数行（ブロック）編集への対応やカラーリングによる視認性の改善、エラーメッセージのカラー化と拡充が実現された。REPL環境やトレースバックでの使い勝手が大きく向上している。
また、「Python」のC言語実装である「CPython」に、実験的なフリースレッドビルドが追加されたのも注目点。「CPython」には、スレッドの競合でデータの整合性が失われるのを防ぐため「Global Interpreter Lock」（GIL）と呼ばれる機能が設けられており、スレッドは同時に1つしか処理されない。この「GIL」を無効化したのがフリースレッドビルドだが、パフォーマンスの向上と引き換えに、既存ライブラリやアプリケーションへの影響が懸念されている。利用の際は注意すべきだろう。
そんなマレンウェッグCEOは、WordPressベースのウェブホスティングサービスであるWP Engineを「WordPressの癌(がん)だ」と批判し、WP EngineからのWordPress.orgへのアクセスをブロックすることを発表しました。WP EngineはマレンウェッグCEOの発言撤回とアクセス遮断の差止めを要求し、裁判所に訴えています。
マレンウェッグCEOはThe Vergeのインタビューに対し、「WordPress.orgは私個人が所有しています。WordPress.orgの所有者として、私を法的に脅迫し、WordPressの商標を使用している企業を宣伝したくありません。そのため、WP EngineのWordPress.orgへのアクセスを遮断しました」と述べています。
マレンウェッグCEOはWordPressの開発プロジェクトの創設者であり、WordPress Foundationのリーダーでもあり、マレンウェッグCEOがWordPress.orgの所有権を持つことは間違いありません。The Vergeは「WordPress.orgはAutomatticからは独立した非営利のプラットフォームであるものの、WordPressエコシステム全体では中立的で独立した裁定者ではありません」と述べています。
マレンウェッグCEOは、WP EngineがWordPressエコシステムの開発に十分な時間と資金を投入していないと批判し、「例えるなら、税金でアル・カポネを捕まえたようなものです。つまり、もしある企業がWordPressで5億ドル(約740億円)を稼ぎ、年間10万ドル(約1480万円)しか寄付していないとしたら、彼らにもっと寄付してもらおうとなるでしょう。だからこそ私たちは法的手段を使って圧力をかけているのです。そうです、私たちは圧力をかけているのです」と語りました。
なお、社内からマレンウェッグCEOの行動に疑問を抱く声が挙がっていることについては、「WP Engine とその親会社であるSilver Lakeによる私とAutomatticへの攻撃は、根拠のないものではあるものの、効果的でした。Automatticの同僚の多くが私と私たちの行動に反対していることが明らかになりました」と自身のブログでコメント。その上で、「2024年10月3日20時(世界標準時)までにAutomatticを退職した場合、3万ドル(約450万円)か6カ月分の給与の高い方を受け取ることができる」と社内に告知したことを明らかにしました。この結果、Automatticの従業員の8.4％にあたる159人が退職したそうです。
WordPress共同創業者のマット・マレンウェグは10月3日づけで “Automattic Alignment” と題したブログ記事を公開、それによると159名がAutomatticを退職したようだ。これは現在WP Engineとの争いが発端で、マットの方針に同意しなかった職員が辞職したようである。この人数はAutomatticの全従業員の8.4%にあたる。
マットのここ一週間ほどの活動はエスカレートしており……
- WordPressの公式ディレクトリにWP Engineのホストからアクセスできないように。
- WP Engineの従業員がWordPressの公式ディレクトリにアクセスできなくなる。この結果、Advanced Cutom Fieldsは更新できなくなっている。
- WordPress.orgがマットによって続々更新される。WP Engineからの訴訟対策なのか、ホスティングページからWordPress.comが消され、コミットログにも”Update the hosting page, per matt”と書いてある。
とくに2番目の「プラグインを更新できなくする」というのはまずく、コミュニティのためとは言い難い行為だ。たとえば今日ACFにゼロデイ脆弱性が発見された場合、WP Engineのユーザー以外もセキュリティリスクに晒すことになる。「乱心」という言葉がその字義通りなのではないか、と勘ぐりたくなるほどである。
さて、もし筆者がこうした精神状態の経営者と一緒に働いていたとしよう。筆者の役職は「弊社が貢献しているのと同じぐらい他社にOSSへの貢献をさせること」だったとしよう。筆者は常識人なので、粘り強く金儲けしている会社と交渉し、少しずつ譲歩を引き出そうとする。一年ほど経ち、ボスは「まだできないのか？」とせっついてくる。「あいつらは泥棒だ。泥棒に賠償させろ」と言う。筆者は「そんな……」と思う。まだ成果は出せていない。そんなある日、ボスがイベントで「あいつらは泥棒だ」と言う。たしかに、道義的には「自分たちの成果の上に乗っかって自分たちよりはちゃめちゃに儲けている奴ら」というのは気に食わないが、パブリックな場でそれを言っちゃあ、おしまいである。筆者はこれまで自分がコツコツ積み重ねてきた成果を否定されたような気持ちになる。その夜、イベントのアフターパーティーを抜け、ホテルのデスクで辞表を書き始める。
こうしたことが実際に起こったかどうかは完全に想像なのだが、本来の意味でのパブリック・リレーションにおいて、WordPressコミュニティは完全にアンコントローラブルな状況に陥っていると言えるだろう。