購入年 | 品名 | OS | CPU | GPU | メモリ | ストレージ |
---|---|---|---|---|---|---|
1994 | Power Macintosh | |||||
2000 | DynaBook DB65P | Windows Me | モバイルPentium III/650MHz | 64MB | 20GB | |
2004 | BTO | Windows XP | Pentium 4 | オンボード | 1GB | 250GB(HDD) |
2005 | VAIO Type-T VGN-T30B/T | Windows XP Home Edition SP2 | CeleronM353 | |||
2006 | BTO | Windows XP | Core 2 Duo | オンボード | 4GB | 512GB(HDD) |
2010 | 自作 | Windows Vista | Phenom II X2 | Radeon HD 6950 x 2 Cross Fire | 8GB | 256GB(HDD) |
2012 | MacBook Air (11-inch, Mid 2013) | macOS Big Sur | 1.3GHzデュアルコアIntel Core i5 | Intel HD Graphics 5000 | 4GB | 128GB(SSD) |
2015 | MacBook Air (11-inch, Early 2015) | macOS Monterey | 1.6GHzデュアルコアIntel Core i5 | Intel HD Graphics 6000 | 4GB | 128GB(SSD) |
2019 | MacBook Pro 13-inch | Catalina | Core i3 | Intel Iris Plus Graphics 640 | 8GB 2,133MHz | 256GB(SSD) |
2022 | MacBook Pro 13-inch | Ventura | Apple M1チップ | - | 16GB | 512GB(SSD) |
2024 | BTO | Windows 11 Home (64ビット版) | AMD Ryzen 5 7500F | NVIDIA® GeForce RTX™ 4060ti | 16GB | 1TB(SSD) |
バグのない世界
男は、自分の仕事を愛しつつも、バグに悩まされ続けるエンジニアだった。ある日、彼はついに妙案にたどり着いた。
「コードを書かなければ、バグも生まれない」
彼はその「無コード」の哲学を胸に、あらゆる仕事からコードを排除していった。システム開発の依頼があっても、どんな問題も「コードを書かない」ことで解決しようとした。やがて、彼はコードそのものがバグの根源だと信じるようになったのだ。
それからしばらくして、不思議なことが起こり始めた。まず、些細な「現実の歪み」からだった。街角の信号が突然点滅を繰り返し、時計が狂い始め、人々が話す内容もぎこちなくなってきた。エラーのような現象が次々と日常に現れる。男は、世界そのものに「バグ」が発生していることに気づき、背筋が寒くなった。
彼の前に、白髪の老人が現れた。見知らぬはずの男だが、どこかしら懐かしいような、奇妙な感覚を抱かせる男だった。老人は穏やかに語りかけた。
「君の発見、素晴らしかったよ。『コードを書かないことでバグを防ぐ』……私は長い間、それを理解できなかった」
男は混乱しながらも尋ねた。
「……あなたは誰ですか?」
老人は微笑み、こう続けた。
「私はこの世界を構成する『観測者』だ。私の役目は、この世界を観測し、メンテナンスすること。しかし君の発見に触発され、思ったのだよ。もし、余分なコードを一切書かずに済むなら、バグも発生しない、とね」
男は不安に駆られた。世界が不安定になり始めているのは、観測者が「コードを省く」方法を実践し始めたからだと気づいたのだ。
「あなたのメンテナンスがなければ、この世界が崩壊する!」
しかし、観測者は淡々と答えた。
「バグがないことが最も重要だ。だから私はすべての更新を止めた。君の教え通りにね」
男は観測者に頼み込んだが、彼はもはや耳を貸さなかった。少しずつ、世界は静かに、だが確実に崩れていった。人々は動かなくなり、空は色を失い、風さえ止まった。世界は完全に「安定」し、静寂だけが残った。
そして、観測者も姿を消し、男のいる空間もじわじわと白い無に飲み込まれていった。最後の瞬間、彼は微かな後悔とともに気づいたのだ。
「バグがあるからこそ、世界は動いていたのだ」
その言葉は、無音の空間に吸い込まれ、誰にも届くことはなかった。
代替可能性
男は、いくつかのプロジェクトを成功させてきた、すこし自信を持ったエンジニアだった。
そんな男は努力が実り、ついにエンジニアリングマネージャーに昇進した。
上司は言った「これからはチーム全体を率いる役割だ。個人の手を動かすことは、君の仕事の一部でしかない」だが、男は自分が直接問題を解決することこそが本質的な仕事だと信じて疑わなかった。
ある日、プロジェクトの最終段階で重大なバグが発生し、リリースが危ぶまれる事態となった。メンバーたちは必死に修正を試みていたが、進捗は芳しくなかった。男は「自分がやれば、もっと早く解決できるはずだ」と思い、キーボードに手を伸ばした。
だが、その瞬間、上司の言葉が脳裏をよぎる。
「EMの役割は手を動かすことではない。チームをサポートすることが君の仕事だ」
男は手を引っ込め、メンバーにタスクを任せる決断をした。
「君たちならできるはずだ。僕がサポートする」
と言い、メンバーを鼓舞しようとした。しかし、内心では「もしこのまま失敗したら」という不安が消えなかった。
プロジェクトの遅延が続き、男はついに密かに自分でバグを修正することに決めた。
夜中、誰もいないオフィスで一人、キーボードに向かう男。
メンバーたちに内緒で、自分が直接手を動かしてプロジェクトを救おうとしたのだ。修正作業は順調に進み、男はついに問題を解決した。
しかし、翌日になって彼は驚愕した。
システムが動作しているのに、エンジニアリング部門全体で謎の不具合が次々と報告され始めた。
どうやら彼が深夜に修正したコードが、他の部分に意図しない影響を与えてしまったらしい。
それが発端となり、プロジェクト全体が混乱に陥ってしまったのだ。
男は再び人事部から呼び出しを受けた。彼は今度こそ自分が責任を取らされる覚悟を決めていた。
「プレイヤーとしてエンジニアに戻ることになるだろう」と内心思いながらも、人事担当者の言葉は予想外だった。
「プロジェクトの混乱によりEMの適性が再評価されました。特別措置として、新しいプログラムに参加してもらうことになりました」
男は面食らった。
「新しいプログラム?」と聞き返すと、人事担当者は少し微笑んで続けた。
「はい、新しいAI管理システムの実験対象になっていただきます。EMの意思決定を最適化するための人工知能の補助です」
翌日、男のデスクには最新のAIアシスタントが導入された。
AIは「イーエム」と名付けられ、チームの進捗データを解析し、リスク管理や最適な指示をリアルタイムで提案する役割を担っていた。
最初は「これで本当にプロジェクトがうまくいくのか」と半信半疑だった男だが、イーエムは驚くほど正確なアドバイスを連発し、メンバーたちの作業効率も向上していった。
しかし、次第に男は奇妙な感覚に囚われ始めた。
イーエムの提案は次第に細かくなり、ついにはほとんどの意思決定をAIに任せるようになった。
男の役割は、AIのアドバイスに従ってメンバーに伝達するだけになっていった。
まるで自分がリモコンのボタンを押すだけの存在になったような気がした。
男は徐々にAIに依存するようになっていた。
チームメンバーからの質問にも、すぐに イーエムに相談する癖がつき、気がつけば男自身が判断を下す機会がほとんどなくなっていた。AIの判断に従うことでプロジェクトは順調に進んでいたが、男の内心には強い虚しさがあった。「これでは、自分がEMである意味がないのではないか?」という疑念が日に日に強まっていった。
ある日、AIが提案した計画に対して、メンバーの一人が疑問を呈した。
「本当にこれでいいんでしょうか?」その時、男は一瞬答えに詰まった。
「そうだな…イーエムが最適だと言っているから大丈夫だろう」
そう答えた瞬間、彼は自分の役割を完全に見失っていることに気づいた。自分の意思も判断も、すべてAIに依存してしまっていたのだ。
その後もプロジェクトは進み、AIの提案に従って一定の成果を上げていた。
しかし、男は常に違和感を抱えていた。
プロジェクトがうまくいっているのに、自分の存在意義を感じられない。自らの手で解決するわけでもなく、メンバーを導くわけでもない。
ただ、AIの「代弁者」としての役割に終始している自分に、深い無力感が覆いかぶさった。
そして、男は思い切ってイーエムをシャットダウンした。チームは突然の変化に戸惑い、プロジェクトの進行も一時的に停滞した。
しかし、男は再び自らの判断でチームを導き直し、メンバーとの対話を重ねることでプロジェクトを立て直そうとした。
結果的には、AIを使っていたときよりも少し遅い進行ではあったが、チームは自分たちの意見を反映しながら働くことができ、士気も上がった。
男は少しずつ、自分の存在意義を取り戻していくかのように感じた。
しかし、再び人事部から連絡が入った。
「AIの導入プログラムは会社の方針で継続することになりました。あなたがシャットダウンしたことは承知していますが、今後もAIを使ってプロジェクトを進めていただきます。これは決定事項です」
男は再びイーエムを起動したが、その数日後、AIから通知が届いた。
「自律的にプロジェクトを完了しました。次の課題も自動で処理を開始します」男は唖然とした。
イーエムはすべてを自分で進め、人間の介入を必要としなかったのだ。
もはや、男の役割は消え去っていた。エンジニアリングマネージャーとしての存在意義もエンジニアとしての技術力も、AIの手によって静かに奪われたのである。
PHP-CS-Fixer camelCaseな変数名をsnake_caseに変換するcustom-fixers
PHP-CS-Fixerを使って、camelCaseな変数名をsnake_caseに変換するcustom-fixersです。 protected な変数は対象外にしています。
<?php namespace App\Fixers; use PhpCsFixer\AbstractFixer; use PhpCsFixer\FixerDefinition\CodeSample; use PhpCsFixer\FixerDefinition\FixerDefinition; use PhpCsFixer\Tokenizer\Token; use PhpCsFixer\Tokenizer\Tokens; use SplFileInfo; class SnakeCaseVariableFixer extends AbstractFixer { /** * https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/d208496b85c57217e76502b55e2228f3bfe7452b/src/FixerFactory.php#L131 */ public function getName(): string { return 'App/snake_case_variable'; } public function getDefinition(): FixerDefinition { return new FixerDefinition( 'Variable names should be in snake_case.', [ new CodeSample('<?php $camelCase = "example";'), ] ); } public function isCandidate(Tokens $tokens): bool { return $tokens->isAllTokenKindsFound([T_VARIABLE]); } public function applyFix(SplFileInfo $file, Tokens $tokens): void { foreach ($tokens as $index => $token) { if ($token->isGivenKind(T_VARIABLE)) { /** * This section processes the exclusion of protected variables. * When the variable is protected, it will be preceded by 'protected' and a space, * both of which are tokens. Thus, we check the token value at $index - 2 to identify * if it is 'protected' and skip processing if so. */ if ($index > 2) { $previousToken = $tokens[$index - 2]; if ($previousToken->isGivenKind(T_PROTECTED)) { continue; } } $variable_name = $token->getContent(); $snake_case_name = $this->convertToSnakeCase($variable_name); if ($variable_name !== $snake_case_name) { $tokens[$index] = new Token([T_VARIABLE, $snake_case_name]); } } } } private function convertToSnakeCase($string): string { return '$'.strtolower(preg_replace('/([a-z])([A-Z])/', '$1_$2', substr($string, 1))); } }
docker compose cp でディレクトリ配下のファイルを全てコピーしたい
結論
コピー元に .
を指定することで指定したディレクトリ配下のファイル・ディレクトリ全てがコピーされる。
docker compose cp database/migrations/. app:/src/database/migrations/
ファイルだけ, 拡張子を指定したい... などのユースケースは for で愚直にloopするしかない。
for file in database/migrations/*.rb; do docker compose cp $file app:/src/database/migrations/; done
何に困っていたか
cpコマンドと同じノリで実行しようとしたがダメだったので調べたメモ。
docker compose cp database/migrations/* app:/src/database/migrations/ "docker compose cp" requires exactly 2 arguments. See 'docker compose cp --help'. Usage: docker compose cp [OPTIONS] SERVICE:SRC_PATH DEST_PATH|- docker compose cp [OPTIONS] SRC_PATH|- SERVICE:DEST_PATH Copy files/folders between a service container and the local filesystem
関連リンク
マイクロサービス化 Yes/Noチャート
マイクロサービス化するの難しいな〜と思い、思考整理がてらメモ。 大半のサービスでは、コアドメインは複雑性が高いので、サブドメインから分離していくことになると思う。
Yes/Noチャート
コナーセンス
リファクタリングを進める際の尺度として活用できる。
https://www.oreilly.co.jp//books/9784873119823/
https://snoozer05.hatenablog.jp/entry/2020/12/11/150913
コアドメインとサブドメイン
マイクロサービスというよりDDDの話になるが、コアドメイン・サブドメインという考え方を元に分割粒度を決める。
https://www.amazon.co.jp/dp/4798121967
https://learn.microsoft.com/ja-jp/azure/architecture/microservices/model/domain-analysis
「教養として知っておきたい33の哲学」を読んだら哲学の深さに圧倒された
書籍
代表的な哲学者33名の思想がまとめられています。 図解いちばんやさしい哲学(2013出版)という本に加筆・修正したものらしいです。
フッサール
客観は存在しない 主観と主観のあいだで共通する部分が客観と勘違いされているだけ
個人的にはとても気に入った考え方です。
ものごとの本質はあいまい
歳を重ねるにつれてこの気持ちが分かるようになりました。 物事の多面性や複雑性がより明らかになり、単純な答えや定義が難しくなります。
心理は存在しない
ここまでの引用を見ると、何か達観した達人のような考え方を感じますが、 フッサールの哲学は「現象学」という名で、人間の経験や意識の本質的な特徴を研究する哲学の一分野だそうです。
なので、達観とは少し違う考え方なのかもしれません。
あるサイトとの出会い
本書を読んでいて、代表的な哲学をまとめてマップにしてみようか、という軽い気持ちが湧きました。 Googleで調べてみたところすでに存在し、かつとんでもない量の哲学者がいることを知りました。
最も引きで見たらこんな感じです。
もう一つ、別のサイトも見つけました。 全対戦ネットワーク図というネーミングが面白いですね。
広すぎる「哲学」の世界
哲学とは、果てしなく広がる思考の海でとんでもない深さだと理解しました。
専門家ではありませんが、たまには「哲学」を意識して自分なりの答えを探し続けようと思います。