EMになってかれこれ1年半ほど経過しました。仕事でほとんどコードを書かなくなってからは1年くらいが経ちます。代わりに組織やヒトのマネジメントが主務になっています。情報収集をしてチームの軌道修正をしたり、メンバーの活躍や成長を助けたり、組織の成果を大きくするための変化を企画したりといった具合です。何かを考えておく、文書にまとめるという仕事が日々大量に襲ってきます。それらを効率よくこなす訓練をしていくと、日々の仕事の不確実性はどんどん下がっていきます。この件は30分で結論を出す！この企画書は1時間でまとめきる！それを見積り通りやれるようになっていきます。パフォーマンスを出す上で、仕事に不確実性はないし許容できないというマインドが強くなるのを感じます。
そんな暮らしの中で、たまに開発タスクをやることがあります。チームの負荷を下げるため一部の保守運用を巻き取ることにしているのです。その仕事に対して、これは1時間でカタをつける！とマネージャーのモードで入っていくと酷い目に遭うことが多いです。エラーと実装をいくら読んでも原因の見当がつかないとか、他の仕様との兼ね合いで問題の箇所がいじりづらいとか、エンジニアをやっていた時は当たり前の日常ではあったものの、予想を超える障害物が当然のように次々と現れます。マネジメントが主務になったからこそ、ソフトウェア開発って大変だな……と改めて痛感します。アジャイルな見積もりと計画、スクラム、DevOpsといった道具はやっぱり必要なんだと再確認できます。そして、そうしたカオスな課題に対して、しっかり計画をして、約束をして、達成をしていく開発チーム、やっぱりすごいなと素直に思います。コードを書かなくなると、この感覚やリスペクトが薄れていく恐怖というのがあって、それを忘れないためにこういう記事に残してみたところです。
私は（LKMLに）直接投稿することができない。2006年に妻のニーナを殺害して投獄されているからだ（I don’t post directly because I am in prison for killing my wife Nina in 2006.）―1月18日付けでフォントデザイナー兼8chan創設者として著名なFredrick Brennanがカーネル開発者向けメーリングリスト「LKML.org」に投稿した内容がLinux関係者の間で話題を呼んでいる。2006年に妻のNina Reiserを殺害した容疑で逮捕され、第一級殺人罪で有罪判決を受けたReiserFS開発者 Hans Reiserが獄中からBrennanに宛てた手紙の全文が掲載されていたからだ。
Brennanは2023年10月、Reiserに宛ててReiserFSがLinuxカーネルから削除される予定であることを伝える手紙を書いており、その返事と返事の公開を求めたところ、11月にReiserから手書きで2通に分けて返信が届き、LKMLでの公開に至っている。
2通目は30枚近い紙数におよぶ非常に長い手紙となっており、Linuxコミュニティへの謝罪、ReiserFS V3の振り返り、ともに開発していた仲間や企業への思い、刑務所内での"社会的スキル"獲得の取り組み、ファイルシステムや名前空間に対して抱いた夢、ロシア人やロシア文化に対する思い（殺害された妻はロシア人）などが綴られている。手紙の最後には「話し合いを通して問題を解決する、そして話し合いで解決できるということを信じ、それを実行する ―私は刑務所でこれらのことを学んだ。結婚する前やLKMLに参加する前にこれらのことを学んでおければよかったのだが。こうしたことが小学校で教えられるような日が来ることを願っている」と書かれており、自身の対人/対話スキルに大きな問題があったことを後悔している様子がうかがえる。
2001年にメインラインにマージされ、一時はLinuxにおけるジャーナリングファイルシステムの草分け的存在でもあったReiserFSだが、Reiserが2006年に逮捕されてからは開発が縮退し、Btrfsやext4といったモダンなジャーナリングファイルが主流となったこともあって、カーネル開発者の間ではReiserFSの削除を求める声がしだいに大きくなっていった。2022年5月リリースの「Linux 5.18」で非推奨となり、以前はデフォルトでReiserFSを採用していたSUSE/openSUSEもすでにReiserFSのサポートを終了、2023年10月リリースの「Linux 6.6」ではメインラインでのサポートも正式に終了しており、2025年にはReiserFSのすべてのコードがLinuxカーネルから完全に削除される予定となっている。Reiser自身の出所も近いと見られているが、それも含め、ReiserFSのすべての歴史が幕を閉じる日は刻一刻と近づいている。
2025年1月リリース予定の次期Linuxカーネル「Linux 6.13」に向けて、マージウィンドウではすでにいくつもの新機能が取り込まれつつあるが、一方でメインラインから完全に姿を消してしまうものもある。Linus Torvaldsは11月21日、Linux 6.13の変更作業においてジャーナリングファイルシステム「ReiserFS」をカーネルコードから削除するコードをマージした（冒頭のコメントはプルリクエストを送ったJan Karaのコメント）。これにより、2001年から23年間に渡ってメインラインコードに存在してきたReiserFSが完全にLinuxカーネルから消えることになる。
ReiserFSは2001年リリースのLinux 2.4.1から標準実装となったジャーナリングファイルシステムで、データベースでよく使われるB-Treeアルゴリズムを採用し、高速な書き込みやファイルオープンを実現することから高い人気があったが、メイン開発者のHans Reiserが2006年に妻のNina Reiserを殺害、第一級殺人罪で有罪判決を受けたことから開発が停滞する。最終的には第二級殺人罪で懲役15年以上という判決となり、Reiserは現在も収監中だ。このことからReiserFSの評判は大きく下がり、また、ジャーナリングファイルシステムとしてBtrfsやext4の勢いが増してきたことから、ほとんどのディストリビューターがReiserFSのサポートを終了した。メインラインでも2022年5月のLinux 5.18で非推奨となり、2023年10月のLinux 6.6ではメインラインサポートが終了、2025年にカーネルから完全に削除する決定が行われ、このことは獄中のReiserにも伝えられていた。
IT業界の三大信じられないもの。
1、営業の「できます」
2、管理職の「大丈夫です」「問題ありません」
3、経営者の「我が社の高い技術力」「お客様からも高い評価」
4、新米プログラマの「できました」「完成です」
一番信用すべきだけど、常に無視される物．
1、熟練プログラマの「ムリです」
米司法省は、米アルファベット傘下グーグルにインターネット閲覧ソフト「クローム」の売却を命じるよう裁判所に求める方針を固めた。事情に詳しい複数の関係者が明らかにした。実現すれば、世界有数のテック企業に反トラスト法に基づく事業売却を求める歴史的ケースとなる。
非公開情報を理由に関係者が匿名を条件に語ったところでは、反トラスト法執行担当者と訴訟に参加した複数の州当局は20日、独占の弊害解消に向け、データライセンシング（使用許可）要件をグーグルに課す是正案もメータ判事に示す予定だ。
訴訟はトランプ政権下で提起され、バイデン政権でも継続された。判事が是正案を受け入れれば、オンライン検索市場と急成長するＡＩ業界を一変させかねない。マイクロソフト解体に20年前に失敗した後、違法な独占が認定されたテック企業を制限する最も大掛かりな動きとなる。
先ほど、Google が新しいハイエンドノートPCの開発に着手し始めていることが報告されましたが、続いて Google は ChromeOS を Android に完全に移行する計画があることが報告されました。
これまで ChromeOS は Chromebook など主にノートパソコン向けに開発されている OS ですが、タブレットも含まれています。しかし、タブレットへの最適化に関しては ChromeOS は Android ほど完成度が高いとは言えません。Google はそのギャップを埋めるため、ChromeOS と Android の両方を利用できるようにしていますが、それでもまだ Android や iPad のようなエクスペリエンスには届きません。
そこで、Google は今年6月に ChromeOS に Android Linux カーネルや Android フレームワークなど、Android の技術スタックを一部採用しはじめています。これにより ChromeOS が Android に近づくことになります。
一方、Android にも Chrome と ChromeOS の機能を近づける技術が導入されたり、Linux ターミナルの導入により Linux アプリを実行することができるようになるなど、Android も ChromeOS に近づいています。また、最近リリースされている Android 15 QPR では、デスクトップウィンドウモードやキーボートとマウスのサポートの改善、外部モニターのサポート、複数のデスクトップといった、生産性向上のための新機能にも取り組んでいます。
IT系の新入社員の教育方法が話題だけど、ちょっと前は大学の新入生で同じ問題が発生していた。「先生は答え知ってるんだから、なんで答え教えてくれないの」と真顔で聞いてくる学生が増えて教師が困惑していた。その世代が入社してきたということ。
あと、PC一台で勉強できるアプリと違って、インフラというのは学生時代には勉強が難しい分野だと思う。家に環境持つのは大変だし、クラウド使ってたらあんまり意味ないし。学校がそういう環境持ってる場合でないとなかなか作って壊してを学ぶのはハードルが高い。
タイパって概念の問題点もこの辺にあると思う。ゼロから試行錯誤して身につく力は「論理的思考」、「粘り強さ」、「仮説を立てる力」といった非認知的能力なので、外形的な基準で評価がしにくい。
・プロなんだから厳しく接するのは当たり前→その通り、問題は見下したり軽蔑するような接し方
・お客様マインドの初心者には冷たく接する→私もそうします
・教えてもらうのが当たり前と思うな→そんなこと一言もいってませんよ？
・ならお前が指導と育成してみろ→正社員時代にはやってました、難しいですよね
・批判しているのは中途半端な自称つよつよ→オンラインはブリリアントジャーク多いですね
様々なハードウェア上で広く使われるようになったOSのLinux。Windowsを中心に扱うPCゲーマーでも、専用サーバーや、近年ではSteam Deckなど、その恩恵に預かることは少なくありません。2024年11月12日、ソフトウェアエンジニアのJeffry Alvarado氏は「Linuxの開発者がソースコードを数行変更したところ、パフォーマンスが2.6％向上した」とX上で報告しています。
今回の修正はLinuxの開発者の1人であるLinus Torvalds氏が行ったもので、「無効なアドレスが指定されたときに実行の遅い命令が実行されないようにする」修正が行われています。この修正によって、カーネルテストロボットによるベンチマークでは2.6％の性能向上が確認できたとのことです。
たった2.6％の性能向上？と思われるかもしれませんが、Linuxはサーバー用途のOSなど、思った以上に広く使われています。Jeffry Alvarado氏は、「Metaのような大企業であればエネルギーコストが数百万ドルも節約できるだろうと言われている」と解説しています。
言いたいことはタイトルに書いたとおりなのですが、2024年12月25日に、新刊『Tidy First?: 個人で実践する経験主義的ソフトウェア設計』が発売になります。
原著はKent Beck氏の『Tidy First?: A Personal Exercise in Empirical Software Design』です。 翻訳はいつもの株式会社アトラクタのアジャイルコーチ3人で行いました（私自身は16冊目の翻訳です）。
ソフトウェアについてのメンタルモデルを構築する最も簡単な方法は、実際にソフトウェアが成長している時にプロジェクトに取り組むことです。Bjarnason氏はこのタイプを「第1世代のプログラマー」と呼び、第1世代のプログラマーはさまざまなコンポーネントの相互作用や特定箇所を変更する最善の方法、ソフトウェアの劣化を最小限に抑える方法、実際には使われていないコードなどをよく理解しています。
一方、第1世代のプログラマーと共に仕事をしているプログラマーのことを、Bjarnason氏は「第2世代のプログラマー」と呼んでいます。第2世代のプログラマーが意味のわからないコードに遭遇した場合は、第1世代のプログラマーが解説することで、第2世代のプログラマーもメンタルモデルを発達させていきます。時間が経過するにつれて、第2世代のプログラマーがソフトウェア開発の中心となり、やがて在職中に書いたコードが大半になると、第2世代のプログラマーが事実上の第1世代のプログラマーになるとのこと。
逆説的になるけど「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まで下げた状態でも計測を実行してみましたが、テーブルごとの傾向も実際の計測時間も大きな変化は見られませんでした。