  |
はてなキーワード: 命名規則とは
そうだろうか
同じ発想でメジャーなのはサンリオのKIRIMIちゃん.だろうがこれも10年前からある
この手の食べ物系シュールキャラミームはもう十分擦られてきたモノのはずだ
それよりも俺が問題だと思ったのは
他のものは迷惑なマナー違反のキャラクター化なのだが、この2名は善行をしようとして勇気がないだけで無害だ
それを同列に扱うことで、気が小さいという個性の範疇までも非難しているように見え、まるで「電車に乗るならそれくらいのコミュ力あって当然だよね？」と圧をかけているように見える
繁華街のクラブではなく公共交通機関でこれは切り込みすぎではなかろうか
この無遠慮なおしつけ感、なんともいい難い違和感を読み手に残していく
しかし、よくよく見ていくと、この動物たちの命名規則はほとんどがくだらない関西系のダジャレである
「わかってイルカ？」のような煽りを含むネーミングにも躊躇がないし、「どないヒョウ」のような関西弁まるだしまであることを考えるに
マナーという「正義」の要求を押し通すに際して横柄さを隠そうとしない態度の言い訳のために「西日本」という属性を使っているようだ
12年無職からの派遣なんだけどやっぱ中小企業は潰れたほうがいい…というか大企業に買収されたほうがいいわ
50年ほど続いている工場だけど
・スマートさがない
・熱意がない人が多い
んだよね。
鉄鋼関係に機械オペレーターとして年単位で勤めているのに鋼の命名規則すら知らない、みたいな感じで基礎知識が欠落している。今やっている仕事について調べようとする熱意すらない。
機械もオンボロで大きいボタンを押すアナログの極み。専用の機械に部品を脱着してボタンを押すだけでデジタル要素皆無。
トラブル対応に出かける際に道具をカゴにまとめるわけでもなく、そのまま積み込むだけ。賢さ皆無。
作業場ももちろん汚い。ボロボロの木床板、ゴム板、それもホコリや金属カス塗れ、機械の操作基盤上や作業台が砂のようなホコリだらけ。5Sの精神皆無。
でも気持ちはよく分かる。流れ着いただけの工場で興味なんて持てやしないだろう。
作業場はすぐ汚れるし、掃除しなくなる気持ちも分かる。でも週5日数時間過ごす場所が汚くて嫌にならないのか？
何より汚い作業場を客が見たらどう思うのか？この時代にITも清潔も糞もない工場内を見て仕事を任せても大丈夫だと思ってもらえるのか？
派遣されて1ヶ月の俺がこう思うんだから、視察に来た取引先の担当者はもっとシビアに工場を見ているだろう。作業員の服装、作業場の備品、棚の整頓され具合、フォークの運転マナー。何もかも、担当者も会社内における自身の信用がかかっているから、なおさらシビアに見ているだろう。実際、再雇用されている生き字引的な方に話を聞くと仕事が減っているそうだ。
この工場はITにしても教育にしても何もノウハウがない。本気で危機感を覚えている中小企業は、職人が培ってきた膨大な作業経験をデータ化したり、知識を平準化すべく資料を整え勉強会を開いたり、IT化にも教育にも力を入れているというのに。
一応、危機感を持っている人は居る。熱意ある上司は居て、忙しい合間を縫って独自の資料を作り教育を施そうとしてくれている。3週間勤めて初めて開かれた勉強会で、3枚あるA4プリントのうち、覚えるべき内容は2行と1図しかなかった。教育の全体図を描いて体系的なカリキュラムを組んだ上での教育という感じではなく、何とかして仕事に興味を持ってもらいたい、でもどう教えれば興味を持ってもらえるか分からず苦慮している様子で、内容は散漫だった。
老朽化した設備と人材では仕事をピンポイントで奪おうと同業他社が出てきた際に負けるのは確実。少しでも作業員の知識レベルを高めたいし、作業を効率化したい。小企業の悪癖と慣習を脱ぎ捨てて中企業へと脱皮したい。足掻いてはいるがどうすれば良いかが分からない。どうすればいいか知識を仕入れるための時間も熟考する時間もない。それが現場の現実で、現場のスキルでは脱皮は遠い。
それなら。
ニッチを突いて成功し、周囲に同業他社が無いことに甘えて危機感も糞もなくヌルッと生き延びてこれた中小企業、設備投資が遅れた中小企業は、熱意とスキルと教育ノウハウとアイデアを現場に整備する技量のある人材を持った大企業に買収されたほうが幸せになれると思う。
大宮アルディージャは、2024年9月にレッドブル・ゲーエムベーハーに株式が譲渡され、事実上レッドブル傘下のクラブとなりました。しかし、現時点ではチーム名が「大宮レッドブルズ」に変更されるという正式な発表はありません。
レッドブルが所有する他のスポーツチームは、多くが「レッドブル」を冠した名称になっています。例として、レッドブル・ザルツブルク（オーストリア）、レッドブル・ライプツィヒ（ドイツ）などが挙げられます。
レッドブルは、世界中で様々なスポーツチームを所有しており、ブランドイメージの統一を図るために、チーム名を統一したいという意向があると考えられます。
大宮アルディージャは、長年の歴史と地域に根ざした伝統を持つクラブです。チーム名を変更することで、長年のファンを裏切る可能性があります。
大宮アルディージャには、地元企業など多くのスポンサーがついています。チーム名変更に伴い、スポンサー契約が変更になる可能性もあります。
チーム名は、地域住民にとって重要なアイデンティティの一つです。チーム名変更は、地域住民の感情を害する可能性があります。
将来的にチーム名が「大宮レッドブルズ」に変更される可能性は十分に考えられます。しかし、チーム名変更には慎重な検討が必要となるでしょう。
レッドブルのブランドと大宮アルディージャの伝統を両立させるような形で、新たなブランドイメージを構築していく可能性もあります。
現時点では、大宮アルディージャが「大宮レッドブルズ」になるかどうかは確定していません。チーム名変更は、様々な要素を考慮して慎重に進められることが予想されます。今後の動向に注目しましょう。
大宮アルディージャの公式サイトや、スポーツニュースなどで最新の情報を確認することをおすすめします。
チーム名変更に関する議論は、ファンや地域住民の間でも活発に行われています。様々な意見があることを理解しておくことが重要です。
競プロと機械学習系のクソコード・クソジャークっぷりが取り立たされてるけど、クソコード・クソジャークっぷりは何も競プロerと機械学習erの専売特許ではない。
https://anond.hatelabo.jp/20240625191650
念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある
入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない
「エラーが出たらとにかくtry-catchしてログ吐いて終わり」
ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる
とか滅茶苦茶多い
異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い
API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない
サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶
とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い
TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ
うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する
結果としてできあがるのは
「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」
っていうコード
最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど
8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる
そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る
これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利
クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり
とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い
競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ
彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない
「これはPoCですから」
とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて
とかしれっと言ってくる
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
とか言ってる奴は50%ぐらいの品質の命名規則やアルゴリズムになってる
20年ぐらいプログラミングやってるっていう40代の人とペアプロしてるんだけど
変数はほとんどがグローバル的な扱いで独自の命名規則で宣言しるし
その命名規則も全然守られてないしスペルミスも多くて読んでてイライラしてくる
根本的な作り方が無茶苦茶でちゃんと動いてるのかバグがあるのかも分からん状態
PR出てくる度に打ち合わせして、そもそものデータ構造とか機能分割について指摘してるんだけど
この前ふと
「そういやJavaで書いたことありますか？Javaだとこんな感じですよね」
って話したらJava知らんと言われた
で、聞いてみたらオブジェクト指向言語で書いたことないし勉強したことも無いとのこと
JavaなりC++なりオブジェクト指向言語で書ける必要は無いけれど
少なくともデータの堅牢性とか再利用性とかの考え方は知っといて欲しい
ぶっちゃけ社内ルールなんて最低限の規則さえ決まってればそこまで影響ないと思ってたけど、違ったわ
フォルダの命名規則が統一されてないから同じジャンルでもあっちこっちにあって死ぬほど探すし、過去の資料もフォーマットがバラバラだから単純に比較できないし、っていうかID,Passとかエクセル、メモ帳、スプレッドシート、サイボウズ、よくわからん自社開発アプリのどれでもいいから統一せえや！そこから担当に聞かなきゃ始まらないってしんどいわ
こういう会社に限って色んなツール使いたがるのも何なんだろうなあ…
実際、これ5年もやってるのにマニュアルもないんですか…？ばっかりやんけ
今までいた会社って最低限は「できる子」だったんだなあ
ましてや優れた人から教えて貰うことでもなく
ただただプログラミングを好きになってモノづくりに熱中することだ
小さい子供がプログラミングに向いているのはモノづくりが好きだからであって
これは大人でも当てはまることであって
何かのモノづくりをするという目的の元に手段としてプログラミングが選ばれ
それに熱中することでいつの間にかプログラミング能力は向上していくのだ
上司から命令されてプログラミング講座を会社の金で受講するとか
Googleを目指して学生時代にプログラミングに打ち込むだとか
そんなのは全然上手く行かないのに定年退職したジジイがラズパイ使ってロボ作りとか始めると上手く行くのはそのせいだ
GitHubが発明したPull Requestはこの楽しみを徹底的に阻害している
「ちょっとこの辺は微妙だけど他のことやりたいから適当に済ませよう」
こうした行為はモノづくりからはほど遠く必要無いものに見えてしまい
「早く動いているところを見たい」
やがて開発者はプログラミングそのものに従事して嫌いになっていくのだ
以前からプロの現場ではもっと厳しい品質管理がなされていたという人がたまにいる
PRによってアジャイルの現場に品質管理がもたらされたと主張するのだ
命名規則やコメントの書き方などルール化できるものは別にレビューなど必要無くツールで弾くことができる
バグがあるかどうかはテストで担保すべきであってレビューで見るべきではない
この手のレビュワーが好んで使う言葉として「技術的負債」というものがある
技術的負債を残さないためにもPRで品質を保つ という主張である
一方で技術進歩は止められるわけが無く10年前に必死でクラス設計したJavaのシステムは
またはレビュワーの考える言語化できない「品質」のために今日もPRはリジェクトされる
人はプログラミングを嫌いになっていくのだ
この議論には相互性がない。あなたと同じように、相手のほうも相手でメインルーチンを走らせており、時にあなたを含む他者をサブルーチン的に利用しているのだから。
つまり、あなた側の視点だけで関わり合いのある他者を機能的に命名してしまうと、あなたというドメイン内での局所的な命名のような命名が、同時に動作しているメインルーチン数だけ存在することになり、命名管理のコストが爆発する（というか、事実上、できない）。他者（あなたにとってのサブルーチン）が、あなたが定めた局所的な命名規則によって呼び出されることを保証できないのなら、それはプログラム的な意味での「呼び出し名」として成立していない。
よって、一意性がある命名を用いて、どのようなドメインからでもおおむね目的のサブルーチンの呼び出しを可能にしていることには、合理性がある。増田のような視点で言えば、会社の役職である「総務課長」や「営業主任」などは、相手が司る機能性に着目した命名とも言えるが、そうした役職は同時に複数存在しうるので、個別のインスタンスを指定して呼び出すには、やはり一意性がある命名を利用することが合理的だ。
また、他者の「機能」は自分との関係で変化する。機能が変わるごとにサブルーチンとしての他者の呼び方を変更することは、両者がドメイン（たとえば家庭）を共有している場合は低コストで可能だが（たとえば子供ができたあとに互いを「パパ・ママ」呼びするなど）、そうでない場合は、機能が変わるたびに命名を変えるのは、メインルーチン側から見ても合理的でない。
人間が他者との相互通信のコストを最小化するには、「他者を機能で命名して、変更があった場合は頭の中でテーブルを書き換える」より、「お互いにユニークに定められたマシン名を直接叩く」ほうがよいのだ。
