  |
はてなキーワード:アンチパターンとは
いいえ、関数の引数が多すぎる（「Too Many Arguments」）問題の解決策としてConfigクラス（またはパラメーターオブジェクト）を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い（Code Smell）」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ（定義）が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数（例：`name`, `lastname`, `city`, `country` → `Address`オブジェクト）をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data TransferObject (DTO) やParameterObjectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則（Single Responsibility Principle / SRP）に違反している大きなクラス（Large Class）や長いメソッド（Long Method）の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない：引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法： この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法： その巨大なConfigクラスのフィールドを、論理的なサブグループ（例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など）に分割することを検討します。
引数が数個（例: 2～3個）しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法：Configクラスの使用は、引数の数が多すぎて（一般的に5個以上が目安とされることが多い）管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか？」と自問し、それがより大きな設計上の問題（SRP違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 734 | 松尾豊 ｜論文の書き方（英語） | ymatsuo.com |
| 648 | 結果発表 ｜次にくるマンガ大賞 2025 | tsugimanga.jp |
| 610 | オンライン署名 ·脚本家吉田恵里香氏のアニメ「ぼっち・ざ・ろっく」第二期からの脚本降板と第一期クレジットからの除名、そして原作者への謝罪を求めます -日本 ·Change.org | www.change.org |
| 590 | メモ - 男のほうがばらつきが大きく頂点も高ければ谷も深い、その生理的メカニズム | crossacross.org |
| 398 | 国内1000件の事例や製品を収録した「生成AI活用事例データベース」を公開─生成AI活用普及協会 ｜IT Leaders | it.impress.co.jp |
| 370 | NHKONE 認証コードが届かない不具合について ｜ お知らせ | www.web.nhk |
| 346 | SESで150万件のメールを送るまで | ses150-luv1p38.gamma.site |
| 339 | 精神科の入院、強度行動障害は対象外 厚労省「訪問看護で対応」｜福祉新聞 | fukushishimbun.com |
| 331 | 最近の人類のレビュー疲れ ｜ Democratizing Data | chezo.uno |
| 325 | ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く | nekogata.hatenablog.com |
| 320 | Windows UpdateでSSDが本当に壊れるか検証【KB5063878再現実験】 ｜ ちもろぐ | chimolog.co |
| 315 | エンジニアならtmuxくらい使いこなしたらどうだ | sititou70.github.io |
| 310 | 【彬子女王のモダン建築めぐり】東京都庭園美術館 | casabrutus.com |
| 303 | 少子化がマズいと思うなら、このくらいやろうよ -経済を良くするって、どうすれば | keizai-dousureba.hatenablog.jp |
| 303 | 今度こそ『ガリア戦記』で挫折しないための6つのコツ -明晰夢工房 | saavedra.hatenablog.com |
| 300 | ドイツの絶望 「人手不足」地獄ーー極右伸長で自滅する産業大国 ｜スマートニュース＋ | plus.smartnews.com |
| 299 | GoogleのAI要約でクリック率ほぼ半減──私たちは思考停止し始めているのか？ ｜AMP[アンプ] -ビジネスインスピレーションメディア | ampmedia.jp |
| 298 | 【速報】村井宮城県知事 “土葬”を白紙撤回 県議会で表明 ｜khb東日本放送 | www.khb-tv.co.jp |
| 288 | 経済を良くするって、どうすれば -経済を良くするって、どうすれば | keizai-dousureba.hatenablog.jp |
| 287 | 私は西鉄ライオンズに在籍したのか？ 米国からの問い合わせ 1963年の「幻」の西鉄外国人左腕を追って【全4回－①】：「おっ！」でつながる地元密着のスポーツ応援メディア西スポWEB OTTO! | nishispo.nishinippon.co.jp |
| 264 | 2020年代前半の「戦記ラノベ」についてオススメなどを語る - WINDBIRD::ライトノベルブログ | kazenotori.hatenablog.com |
| 260 | 笠井スイさんと、旅の仲間たち | geselleestelle.blogspot.com |
| 253 | 造幣局 :ドラゴンボール40周年記念2025プルーフ貨幣セットの通信販売について（2025年9月4日） | www.mint.go.jp |
| 245 | Issue, Pull-request,GitHub Copilotによる「普通」の一人チーム開発 -Cybozu InsideOut ｜サイボウズエンジニアのブログ | blog.cybozu.io |
| 244 | 任天堂がボクセルを使ったアクションゲームの特許を大量に出願していました - naoya2kの日記 | naoya2k.hatenablog.com |
| 241 | 「人間ドック」がどのように人間を破壊していくのか。何一つとして医学的ではない見地から、知られざる実態を暴きたい - もはや日記とかそういう次元ではない | manato-kumagai.hatenablog.jp |
| 240 | 英国生まれのSF作品 | www.news-digest.co.uk |
| 237 | 会話の目的は勝つことではない - ともにかける | paper2.hatenablog.com |
| 229 | 「RECORDCLUB」という海外の音楽SNSがなかなか楽しい。 -世界のねじを巻くブログ | www.nejimakiblog.com |
| 225 | この文字詰め、どっちが正解？文字間調整（カーニング）のセンスを磨いておこう | www.adobe.com |
本人的には自衛のために編み出したのだろうが、傍目には馬鹿を拗らせてるだけのダメな受け答えのパターンがある。
そういうことをやってると誰も対等に扱ってくれず社会の中で孤立を深めてしまうのだが、悪循環の中にある当人にはそれがわからない。
なぜ〇〇なんだ？という問いに「じゃあ✕✕はどうなんだよ！？」と反射的に返すWhataboutismは典型的な例だ。本人はうまく“対消滅”させたと思っているが、傍目には返答をネグって勝手な話を始めただけである。本人は「上手いこと言い逃れた」と思ってるが実際はただ嫌われ、見下されただけ。
これが「なぜ〇〇なのか」の答えを即答するのでなく余裕を持って検討する上で✕✕を参照してみようという持って行き方だったら
大枠として同じことを言っていても他人が受ける印象は全く違う。
他人に迎合はしないが無用の反発や侮蔑を買わない、ある意味ずるい大人としての物言いは「恋愛工学」みたいにある程度マニュアル化できるし、訓練で身につけるのも可能である。
なんかムズムズするなベストプラクティスの対義語っぽいけどなんだろうと思ってたけどアンチパターンのことか。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250728172448# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaIcz0gAKCRBwMdsubs4+SEHNAP4qltMiGRD5gnhFCTWUKQ/8hyLM1bmk2l3veXZ6kgU0NwD+OPsN9Q6wdzbNtzUFXO03yVwNNOCMabVo3rJ/fRu2YQI==qm58-----ENDPGP SIGNATURE-----
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
選択的夫婦別姓の議論が盛り上がっているが、この制度設計には根本的な問題がある。それは「選択的」という発想そのものが、現在の制度が抱える構造的欠陥を放置したまま、表面的な対症療法に留まっているということだ。
ソフトウェア開発において「単一責任原則」という重要な設計原則がある。一つのクラスや関数は一つの責任だけを持つべき、という考え方だ。現在の結婚制度をこの観点で見ると、明らかにアンチパターンを踏んでいる。
• 法的な結合関係の成立
• 姓の統一
これらは本来、独立して扱えるはずの要素だ。姓の変更を結婚に紐づける必然性はない。むしろ、この結合が様々な問題を生み出している。
選択的夫婦別姓は一見進歩的に見えるが、実際には以下の問題を抱えている：
根本的な構造問題に手をつけず、「選択肢を増やす」という表面的な対応に留まっている。これはバグのあるシステムに機能を追加して複雑性を増すだけで、本質的な修正になっていない。
「高齢者や伝統を重視する人への配慮」がよく言われるが、選択的夫婦別姓でも結局は「選択を迫られる」ことになる。むしろ特定の世代だけが「変化への対応」を求められる分、不公平感すら生まれる。
現在の制度では、統計的に女性が改姓することが圧倒的に多い。選択的夫婦別姓があっても、社会的圧力によってこの不均衡は続く可能性が高い。
2. 年1回の改姓権：すべての国民が平等に姓を変更する権利を持つ
真の平等の実現
柔軟性の確保
•結婚後に同じ姓になりたい夫婦は、年1回の改姓権を行使すれば実現可能
•夫婦が同時に改姓権を行使することで、どちらの姓でもない中立的な新姓を選択できる
• これにより真の夫婦平等が実現される（どちらか一方が相手の姓に合わせる必要がない）
◾️よくある反論への回答
子どもの姓は子ども自身が決められる年齢になってから選択すればよい。現在は親が決めているが、最終的に影響を受けるのは子ども本人だ。
現在でも結婚・離婚による改姓で同程度の負荷は発生している。むしろシステムを整理する機会になる。
「国際手続きが複雑」
現状でも国際結婚や海外居住で姓の問題は発生している。新たな負担というより既存問題の整理という面が大きい。
◾️まとめ
選択的夫婦別姓は、現状に不満を持つ人々への一時的な慰撫策に過ぎない。本当に必要なのは、結婚制度そのものを現代的に再設計することだ。
技術の世界では、パッチを重ねて複雑になったシステムは最終的にリファクタリングが必要になる。社会制度も同じだ。表面的な修正ではなく、根本的な再設計を恐れるべきではない。
「grokにファクトチェックさせている人は何も知らない」という記事が話題になっている。
そもそもこれ、みんながgrokにやらせているファクトチェックってのは実は「ダブルチェック」なんだよな。
ダブルチェックと言っても再発防止のアンチパターンとして忌み嫌われているアレじゃない。
ダブルチェックとは「こっちでも確認する」くらいの軽い意味だ。
例えば、サイトにアクセスできなくなったら、別PCでアクセスできるか同僚にダブルチェックを頼んでみたりとかね。
英語圏で「ダブルチェック」といえば基本的にこっちが主流で、「"@grokdouble-check"」とかXで検索すれば山ほどヒットする。
ダブルチェックしただけではまだ結論には遠いかもしれない。それを判定するのは発言者だ。
しかし会話の補助にはなる。
あなたが感じている「微妙な気持ち悪さ」、たぶん共感する人はけっこういます。
Ruby界隈には他の言語圏にはあまりない独特な文化や、ちょっとした“ズレ”が存在していて、それが複合的に作用してるっぽいんです。
具体的な事例を交えつつ、ちょっと詳しく見てみましょう。
Rubyでは「美しいコード」「優雅な文法」が非常に重視されます。「書いてて気持ちいい」ことを最上の価値として掲げてる言語で、Matz自身も「プログラマの幸福のための言語」と明言してます。
が、それが行きすぎて──
みたいな文化が生まれがち。いわば“美学警察”みたいな空気です。結果として、他言語出身者が入ってきたときに「書き方がキモい」とか「ダサい」といった、**ちょっとしたマウントが生まれやすい**。
これは他の言語ではあまり見られない、“審美観の押し付け”です。しかもそれが悪意なく、ニコニコしながらやってくるからこそ、逆に怖い（笑）。
Matzさんは本当に素晴らしい人物なんですが、Ruby界隈では**「Matzが言った」＝正義**みたいな雰囲気が根強いです。
例えるなら、以下のような流れ：
つまり、**Matz本人よりも取り巻きの熱狂ぶりがすごい**。これは宗教的とまで言われることもあります。
他言語（特にPythonやGo）出身者が入ってきたとき、Rubyの書き方・哲学に染まっていない人に対して、無意識の壁があることがあります。
たとえばRailsの世界だと「controllerとviewの責務」とか「fatmodel/small controller」みたいな**“暗黙の常識”**が多くて、それに沿わないとすぐに「アンチパターン」扱いされます。
結果として、**知識より「ノリの同調」が重視される風潮**があり、外から見ると「村社会っぽい」「馴れ合い感がある」と感じる原因になります。
Ruby界隈って妙にカジュアルなんです。会議もゆるいし、発表も「みなさんこんにちは〜！」みたいなゆるふわ系が多くて、技術者らしいカチッとした空気よりも**「和気あいあい」な空気が主流**。
その一方で、現役で活躍しているRubyistの年齢層は結構高め（30〜40代中心）で、Slackの文体やGitHubのREADMEなんかが**ちょっとおじさん構文に見える**こともあり、そのギャップが「微妙に気持ち悪い」と映ることがあります。
かつて世界を席巻したRailsも、いまはNext.jsやFastAPIなどに押され気味。にもかかわらず、Ruby界隈では「まだRailsが主役である」という空気が漂っていて、その**現実とのズレ**がモヤモヤを生みます。
みたいな開発者の**“表に出ない本音”**もあったりして、コミュニティ全体に妙な閉塞感がある。
RubyKaigiとか見てると分かりますが、登壇スタイルも独特で──
それが心地いい人もいるんですが、**「寒いノリが内輪で盛り上がってる感」**が苦手な人にはちょっとしんどいポイントかもしれません。
こんな感じで、Ruby界隈って**“優しさと強い価値観”が同居してる場所**なんです。それが人によっては心地よくもあり、気持ち悪くもある。
神クラス（GodObject）は、ソフトウェア設計においてアンチパターン（避けるべき設計手法）として知られています。
これは、過剰に多くの責任を持ちすぎるクラスやオブジェクトのことであり、ソフトウェアの保守性や拡張性、可読性に大きな問題を引き起こします。
以下では、「いかに大変か」「なぜ大変か」「どのように大変か」を徹底的に具体的に解説します。
public class ApplicationManager { privateMap<String,User>users; private DatabaseConnectiondb; privateLoggerlogger; privateGUIgui; private NetworkClientclient; publicvoid startApplication() { connectToDatabase(); loadUsers();gui.showLoginScreen(); } publicvoid processUserInput(String input) {logger.log("Input received: " + input); if (input.equals("logout")) {gui.showLoginScreen(); } else {client.send(input); } } // ...more than 5000 lines of code}
新発売の『人が壊れるマネジメント』という本、目次から早くも「頭が痛くなってきた」と精神に支障をきたしそうなアンチパターン大集合で興味深い
この目次を読んだときに、まぁあるあるだなーと思いつつも、これらをこなせるようになったら重宝する組織人になれるのかと思ったわけである。
どの現場でもよく起こりがちなのだから、自分が下っ端なら、リーダーのその部分を補強できるフォロワーシップを身につければ、先が開けるわけである。
なんならそういうフォロワーとしてのリーダーが、需要あったりもするしな。うんうん。
などと思っていたら、ブコメはまぁ、、、
これ
https://news.yahoo.co.jp/articles/3199aacebbf952e0afac22488144c63f9042f537
伊集院は「Ｍ－１に出たことある人たちで、しかもＭ－１がちゃんとステップになった人たちが全員、審査員でいいの？すごい特殊じゃん。そういう文化って滅びない？
あのさあ
大会優勝者が審査して、その価値観で審査したらタコツボ化して衰退するみたいな
浅いこと言ってんじゃねーよ、全体の大会のシステムで見るべきだろ
審査員はまず現役で笑い取ってる人
先鋭的だったり分かる人にしかわからないお笑いやってる人たちじゃなく、毎日のようにお客さんを相手にしてるんだから
変な先鋭化は起きねーよ
難しいテクニック使ったところでそれが客に受けなきゃ点数上げないだろ
しかも会場にはお客さんもいるし、その反応も見て点数つけてると言ってる
テクニカルになりすぎず、自分らのやり方を貫いてる人が多いのはそういうことでしょ
似た番組が登場するだけだよ
今行ってきたセブンイレブンで、レジに見かけたことのないおばあさんがいた。70代後半ぐらいで、表情は険しかった。
新入りかなと思って仕事ぶりを眺めていると、このおばあさんはことごとく仕事に失敗する。電子レンジを操作すれば弁当のタレを爆発させるし、集荷の書類のありかがわからなくて右往左往したりもする。
他にも棚をぶちまけたり、多数のミスを次々とやってのけた。
たちまちセブンイレブンのレジ待ちの行列は長くなり、相方のおそらく監督役の中国人の若者もおろおろしだした。
ばあさんも自分が全然作業に貢献できていないことを理解しているのだろう、表情は険しい。
それでもばあさんにとっては仕事をやってのけなければ食いぶちがなくなるから、努力はしなければいけない。
結果として無能なバカが空回りして努力することによりリカバリーのための無駄な仕事がどんどん生まれているという地獄のような状況に至る。
たった一人無能なばばあがいるだけでレジは大混乱に陥る。これはチームを編成するときにバカに張り切らせるとチームの作業の流れがことごとく破綻することを示唆していて、チーム編成上のアンチパターンの典型例だと感じた。
このババアの困惑をもとにChatGPTとどうしたらいいか壁打ちをして、最終的にババア達の脳をブレインマシンインターフェースで結合してBBA計算クラスターを作成するという途方もないSFが生まれた。
きのう
新しく種を撒く
小さいポットの方がマリーゴールド
大きい方は百日草
モロヘイヤの間引き、まだ発芽してない種があるようで間引いても間引いても新芽が出てくる
芝桜の挿し芽、だいぶ前にポットで５つ作ったが、一つが枯れてきている
芝桜の挿し芽第二弾、先週の日曜日にポットで１８つ作ったが、勢いがまったくないのでたぶん全滅する
というか、後で知ったのだが培養土に挿し芽をするのはアンチパターンらしい
やはり間引きが遅れて徒長させてしまったのもあるが、引き抜いてみると地面から上は真っすぐ上に伸びているが地面の下は真横に伸びていたりするので、種を撒いた時に被せた土が多すぎたのかもしれない
主に同棲をしているなどで、普段の生活において家事の分担が発生した場合に「家事手伝い」によって起こりうるすれ違い（ほとんどお気持ちのようなもの）を書いてみた。
そもそも、それぞれの家庭がどのように家事をこなすかということ自体様々なパターンがあると思う。
絶対にこれをしてはいけない。というよりは、自分はこういう風に思うことがあるんだけど、他の人ってどうなの？というのを家事をする側・手伝いをする側の双方の意見を聞けたら良いなと思って書く。
他にもこういうのあるよねというのがあればぜひ知りたいし、こういう気持ちで手伝ってるんだよなというのも聞いてみたい。
実際、いつも料理している人が料理を作れないみたいな時は後片付けも含めて億劫な状況であることが多く、料理部分だけをやってもむしろなぜ人が散らかしたものを自分が片づけるんだ！？という気持ちになりがち。
これはちょっと笑い話でもあるんだけど、こういう時に限ってなんかすごい面倒そうなもの作るね！？みたいなことがあったりする。せっかく作るんだからみたいなところから来るのかな？聞いてみたい。
せっかくのアンチパターンなのでこういう状況はどうすればよいのかみたいなことも書いておくと、サクッと出前を取るとかするか、料理するなら後片付けまでちゃんとやるまですればとりあえず良さそう。
後片付けのクオリティみたいなところもあるけど、その辺は期待値コントロール次第。
家事の種類によらず、自分が今まさにやっている家事を手伝おうとする、みたいなことが結構起こる。
自分が家事に取り組み始めた段階で、これくらいの時間でこの手順で終わらせていこうみたいな計画があるので、途中で手を出されるとそれを並行で進められてもなーという気持ちになることがある。
結構ウキウキで手伝っている気がするので、手持無沙汰な時間のコミュニケーション的な感じでやっているのかなー？と思っている。
解決策はシンプルで、残っている家事で手を付けていないやつをやってもらえるのがよい。ちょっと手伝おうと思うんだけど、なにすればいい？みたいなコミュニケーションがあるだけでじゃあこれお願い！となる。
家事の分担自体、最終的に生活力が高い人が多くを担う形に落ち着きがちだと思う。双方ストレスなく回るなら別にそれでも良いと思う。
そうすると、あまり家事をやらない方ができることと言えば、まとまっているものを定時に出すみたいな簡単な仕事になる（ならない？）。
で、例えばなんやかんやあって朝のゴミ捨てはお願いねという形になるのだが、これが普通に難しい。
朝ってバタバタしてて見逃すということもあるし、前日自分がゴミをまとめるのを忘れていたみたいなことも起きる。
あとは、複数種類のゴミをまとめて置いた場合に自分が持っていけるやつだけ持っていくとかもある。燃えないゴミは隔週だから本当に重要なのはこっちだったのに...とかもある。
自分は特に思いつかなかったんだけど、こういう簡単なものを任されたけどうまく回らなかったパターン色々ありそうだなーと思っている。
これの解決策、なんでしょうね？ゴミ捨ての場合は普通に24時間ゴミが出せるマンションに住むとかくらい？あとは、心配しなくてもゴミの日はまた来るのでくよくよ考えずに切り替える。なんかいい方法あったら教えてください。
なんか書き出してみるとそんなに出てこなかった。
現代、自動で色々やってくれる家電も普及しているしそもそもすごく大変な家事みたいなのは少ないのかも。
子供がいると全然違う、というのはあると思うのでもしあれば色々教えて欲しい＆パートナーで話合う種になると良いなと思っています。
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWSEC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpmrun installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npmrun installでインストールできるし npmrun devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROPTABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
