  |
はてなキーワード: プラクティスとは
Ruby全盛期のちょっと後くらいからWebエンジニアをしているんだけど、React.jsがいろんな意味で扱いにくすぎる
関わっている人にもフロントエンドエンジニア(=React.jsしかやりたくない)が多いのでここに強めの毒気で吐き出しておく
ライフサイクルや裏側の仕組みをなんとなく理解していないと使えず無意味に複雑
useEffect一つとっても~~の場合はuseStateでいけるとかTIPS集みたいのがあるけど、そういうウンチクみたいなのわかってないと使いこなせないのは仕事増えてない？
仮想DOMで高速化とか言っているけどライフサイクル理解しないと速度でないよね？いつものプロジェクトそんなにちゃんと書けてる？jQueryで良くない？
ベストプラクティス知っててちゃんと設計しないと改修する工数がすごいことになる
そもそもプロジェクトにおいて作るものは都度変わっていくので完璧な設計は存在しない。なので、設計をきちんとしないとカオスになるのはReact.jsのほうが間違っている
React.jsと別のフロントエンドライブラリ比較するだけで空気悪くなるので正直フロントエンドエンジニアの人の前で話せない話題がある
なぜかフロントエンドライブラリをReact.jsしか許さない人が多いのはなぜ
言うまでもないけどNext.jsの記法はひどすぎる。Remixは良いけどそれならもうReact.jsじゃなくていい
数少ないメリットだったエコシステムだけど、もうReact.jsしか対応していないことなんてほぼ無い
フロントエンドリッチでアクセス数ものすごいサイトを運用するのにフロントエンドライブラリが必要だった時代にReact.jsを開発する必要があったのはわかるけど、もっと便利なフロントエンドライブラリあるし正直時代遅れなのを理解してくれ
あるんだろうけど調べ方がわからないから知ってる人いたら教えてください。
今はアラサー実家暮らしで、特に出る予定はないんだけどいつか出るかもしれないから知識として入れておきたい。
学生や若者じゃないので節約とかはそこまで重要じゃない、むしろ金かけてでも楽にする方法が知りたい。
現時点で知りたいこと・調べられること・気になることを自分用にメモっておく。思いついたら足す。
探す段階でこれを読む。
https://www.hageatama.org/20230620/1687265125
https://www.earth.jp/gaichu/hukai/
家具ない段階で燻煙剤、いいね！トラバありがとうございます。家具あってもやっちゃえと思ってた。
経典：https://anond.hatelabo.jp/20141023184519
家事で一番好きじゃない。洗濯というよりは「干す」工程が嫌。ついでにアイロンも。
なので乾燥機付き洗濯機を買う。ガンガン洗える・乾燥できる服を選んで買う。
ドラム式がいいらしいけど狭い部屋だと置けないことがあるらしい。要確認。
完全乾燥機頼りだったらベランダの日当たりとかあんまり気にしなくていいのかな。
どうしたらいいか定まってない。
整理整頓はできると思うけど、ホコリを取る方の掃除が積極的にできる気がしない。目についたらやるくらいの感じになる。
クイックルワイパーでいいのか、掃除機あったほうがいいのか。広い部屋でなければルンバはいらないような気がするが、あると便利なのだろうか。
浴槽に浸かる習慣がないので使う頻度は少ないだろうが、カビは生やしたくない。
https://www.asahipen.jp/column/housecare/bath_mold_prevention/
今の実家は元から脱衣所までカビだらけだから何もやってない。なので何としてでも習慣をつける。
手入れが一番楽な方法ってなんだろう。
3ヶ月にいちど家事代行で水回り
ブコメありがとう！そうか、家事代行って範囲も日程もスポットでもいいのか。
食洗機か最悪紙皿・紙コップでいいだろうと思ってたけど、そもそも食器洗いはそこまで嫌いではないので優先度低め。調理器具を洗うのは嫌いだが、極力料理をしたくないのでそんなに出ないだろう。
導入したくなったときのために食洗機がおける部屋かどうかはチェックしておく。
極力やりたくない。いい電子レンジといい電気調理器を買う。今もそう。
火が怖いのでできればIHがいい。ガスコンロついてる部屋で自分でIH調理器使うのが一番いいんだろうけど、それならまあ普通にコンロ使う。
実家では料理時に換気扇を付ける習慣が無く、スイッチがどこにあるのかも大人になるまで気にしたことがなかった。浴室もついているのは知っていたがつけるタイミングが分からなかった。トイレはそもそもついてなかった。
https://journal.anabuki-style.com/turn-fun-on-or-off
一方でトイレやキッチン・浴室などについている換気扇は、長時間運行に対応していないものがあるため、24時間つけっぱなしは故障の原因となりうることがあります。したがって使う時だけつけるスタイルが正解。
浴室：入浴後はドアを閉めて換気する
探し方がわからない。
今だとネットで条件検索→出てきた不動産屋に行くって感じなのかな～
決めとけっていろんなところに書いてあるから考えてみる。トラバ見て気づいたのもある。ありがとうございます。
バストイレ別
独立洗面台
駅徒歩10分以内
洗濯機を室内に置ける
ゴミ捨て場が近い
ワンルームより上（1DK, 1LDK以上）
2階以上、できれば3階以上
希望の中で一番高そうな駅で全条件入れても全然予算内でたくさん出てきたけど、囮物件というのがあるらしいからどうなんだ…
これらの投稿から、日本のIT業界における人材育成や組織文化に関する課題が浮き彫りになっていますね。いくつかの重要なポイントを整理してみましょう:
競技プログラミングや機械学習の経験者は、特定の分野で高い技術力を持っていますが、実務で求められる幅広いスキルセットとのミスマッチがあるようです。
技術力だけでなく、チーム内でのコミュニケーション能力や協調性が重要であることが強調されています。
学術的な環境や競技での成功が、必ずしも実務でのパフォーマンスに直結しないという現実があります。
効率性だけでなく、可読性やメンテナンス性の高いコードを書く能力が求められています。
会社組織や指揮命令系統、プロジェクト管理の基本的な理解が不足している事例が挙げられています。
技術スキルだけでなく、ソフトスキルやビジネス知識も含めた包括的な研修プログラムを実施する。
経験豊富な先輩社員が新人エンジニアをサポートし、実務スキルや組織文化の理解を促進する。
インターンシップや社内プロジェクトを通じて、実務経験を積む機会を増やす。
定期的なコードレビューを通じて、コードの品質向上とベストプラクティスの共有を図る。
セキュリティ意識向上のための定期的なトレーニングやワークショップを実施する。
技術専門職と管理職のキャリアパスを明確にし、個々の適性に応じた成長機会を提供する。
これらの施策を通じて、技術力と実務能力のバランスが取れた人材育成を目指すことが重要です。また、採用段階での適切な評価基準の設定や、組織文化とのマッチングにも注意を払う必要があるでしょう。
真面目に議論するなら、お好み焼きをクラスとするかも怪しくなる。
オフトピだがね。
オブジェクト指向が栄華を極めたあの時代、責任、関心、主体性、凝集、アイデンティティ、is-a has-a、… 研究者やギーク、仙人らによって、あらゆる説明がされたが、結局、オブジェクト指向は現実世界を捉える人間の感覚の応用でしかなかった。
「モノ」と思える奴をクラスにすればいい。
それ以上でも以下でもなく、あとはプログラミングの構造を整理するために有効に使えるケース・バイ・ケースの妥協点を探すことになる。どうモデリングすべきかの議論は収穫が少ない。いや、極めれば霧の向こうで信じがたい洞察を垣間見れる可能性はあるにはあるが…、しかし多人数でソフトウェアを維持管理するのが正解だと分かった今、属人性を排除するためには霊感を説明するよりシンプルに留めるのがベスト・プラクティスだ。
プログラマーの関心が関数型に移ったのは、そういう経緯もある。数学をバックグラウンドに持つ関数型言語をバックグラウンドにする方が、ミーハーな技術屋連中の興味を引けた。
在宅ワーク／警備員で「喋り方」を忘れてないか心配になってきたあなたに朗報です。
この方法を使えば普段から人と話していなくても、まるで人に話しかけるように自然に発声練習が出来ます。
高い道具を買ったり、時間を取られるルーチンを取り入れる必要もありません。
仕事をしながら、あるいは家事をしながら、ひとりごとを言うように気軽に発声練習が出来ます。
パソコンの前でやれば、オンライン会議の前に声を慣らすことも出来ます。
立っていても座っていても、寝転がっていても構いません。
ほんの小さな、脳をハックする工夫ひとつで、あなたの発声の意識が見違えるほど変わります。
さらにさらに、これは英語など外国語の発音練習にも効果があります。
さて、その方法とは↓
「『耳』の絵を描いて、それに話しかける」ことです。
『耳』の絵は、簡単なもので構いません。あなたが耳と認識さえすれば良いのです。
その『耳』に、ちゃんと聴き取らせるように、話しかけて下さい。
内容はなんでも構いません。挨拶でも、ひとりごとでも、日本語でも、英語でも。
ひとはそこに『耳』があると意識するだけで、おどろくほど発声に対する意識が変わります。
耳に話しかける習慣を付けるだけで、あなたの日常の言葉も、非日常の言葉も、飛躍的に聞きやすいものになります。
こんな簡単なことで本当に？ という気持ちもあるでしょうが、騙されたと思って是非いちど試してみてください。
一日も続けていれば、その効果を必ず実感できるでしょう。
「業務経験で技術的に難しかったことある？」って聞かれるんだけど、普通のWeb開発であまり無いよな。
こちとら15年ぐらいエンジニアやってるんだから、大体のことは対処できるし、わからなくてもググればほとんどのことは見つ
必要があればクラウドのAPIとか使えばいいだけだし。AWS無い頃に比べるとベストプラクティスに沿えばいいだけなので、だいぶ簡単になってると思うんだけど。
多くの場合、「難しさ」がどこから発生するかというと制約条件と要求水準とのバッティングだと思う。
どうしてもこの速度を達成したいが使えるサーバーの数には限りがある、みたいな。webは知らんので適当だけど。
そういう経験はないんだろうか？
久々のggrksだな。
世界トランスジェンダー・ヘルス専門家協会（WPATH）は、性別違和（gender dysphoria）
の科学的研究と、トランスジェンダーの健康のエビデンスに基づくベスト・プラクティス
のために活動する、唯一の国際的で学際的な専門職組織です。当協会は、医学、メンタル
ヘルス、法と倫理、そして科学研究の分野に 2,200 人以上の会員を持つ非営利団体です。当
協会は、科学者と医療提供者が力を合わせ、当該領域に関する知識を交換することを目的
として 1979 年に設立されました。国際的に認められた「トランスセクシャル、トランスジ
ェンダー、ジェンダーに非同調な人びとのためのケア基準」（最新版は第 7 版）（SOC v7）
を作成し、Web サイト（www.wpath.org）には日本語訳も公開しています1。当協会は世界
各地の政府に対し、トランスジェンダーの健康と人権および市民権に関する助言を行って
います。
これまで株とか投資信託、外貨とかの投資は一通りやっていて、旧NISAや新NISAも当然やっているわけだが、最近のNISA推し、特に「脳死でオルカン積み立てておけばいい」という風潮には違和感がある。
脳死でリスク資産にお金を突っ込んでいたら、文字通り死ぬのでは？
前提として、お金は使うために貯めるのであって、使う時には現金化する必要がある。
子供や配偶者がいれば、マイホームとか教育資金で早めに必要になるけど、40代独身中年がターゲットにするのは、定年や再雇用のタイミングの60歳〜65歳。
そうすると、短ければ10年ちょっと、長くてもあと20年しかないわけで、暴落しても20年、30年待てばいいということにはならない。
ワーストケースとしては定年直前に株価のピークとリセッションが来るケース。その場合にリスク資産が100%だとダメージが大きいので、定年に向けて現金（あるいは債券などの比較的安全な資産）の比率を高めていくのがセオリーになる。
DCやiDeCoの商品には「ターゲット イヤー ファンド」というのがあって、これは定年に向けて株式などのリスク資産を徐々に減らして安定資産に切り替えていく商品。
中年を過ぎたら、ドルコストでリスク資産を積み立てていくのではなく、徐々にリスク資産を売って現金比率を高めていくことを考えないといけない。
（DCやiDeCoは退職や一括受け取りで強制的に現金化されるので、もっとシビア）
とはいえ、定年後も資産を運用して増やしていった方がいいのでは？という考えもあるけど、将来受け取れるお金を増やすのであれば、年金受給を5〜10年遅らせて42%〜84%増やすのが確実。
となると、年金受給（70歳〜75歳）までのつなぎに自己資金をあてる必要があるので、NISAなど現金化しておく必要がある。
年金を受け取る前や年金をあまり受け取らずに死んだら損ではあるけど、独身なら相続させる相手がいないので関係ない。
確実にお金を使い切るのであれば、これがベストプラクティスではあるけど、老後に証券口座の残高を見てニヤニヤすることが出来なくなるのはちょっと残念だよね。。。
もともとは「シェルスクリプトをプロダクションで動かしてる」だけでヤバいと主張してたけど、さすがに旗色が悪くなってきたから
個人的には初心者プログラマがUNIX哲学周りの本読んでハマるか、キャリアアップできなかったエンジニアが使うのがシェルスクリプトだと思っているが。
私はPM。要件決め、設計などは得意だが、細かい技術的な部分はよくわかっていない。
チームリーダーB：経験豊富。全体設計もできて、コーディング速い。顧客折衝もできる。
新人C：経験浅い。コーディング遅め。devopsやプログラム言語についての知識がある。こだわりが強い。SNSでもいろいろ発信。
私は板挟み。
チームリーダーBは頼りになる。新人Cも最新の技術的な動向を追っていて、いろいろ知っていて関心する。いわゆるベストプラクティスというのは新人Cが提案するやり方なのかな、と思う
たとえば、クラス設計はインターフェースを用いてもっと疎結合にコードを組むべきだとか、テストコードのカバレッジをもっと上げないととか、言ってることはもっともだと感じる。
チームリーダーBはそういった細かいところにわりと無頓着なのかもしれない。ずっとやってきたやり方に固執してる部分もあるだろう。
私が若かったころは先輩のやり方は絶対だったため、こういった揉め事は少なかったように思うが、
最近は新人も学生時代にネットで多くを学んでいるため、知識が豊富で理論武装もすごいため、先輩が言い負かされてしまうケースも多い。
私の意見としてはBもCも良い部分があるため、どちらの意見も採用したいところだが、相性がよくない。
BはCのやり方だと、他のメンバー（DやE）の面倒もBが見ることになり、自分の負担が増えると言う。
ただ、保守性の高いプロダクトにしておかないと、長い目で見たときにあとあとキツくなってくる気もする。
あと、CはCで時間を掛けてばっちりテストコードを書いてるはずだが、経験が浅いせいか、テスト環境にデプロイさせると、かなりバグを発生させている。。
どうしたらよいだろう。
アフターコロナと呼ばれて久しいこのタイミングで、副業を始めたいと思っている。
当該領域に造詣の深い増田諸氏におかれましては、さまざまな失敗談にもとづくベストプラクティスをご存知なのではでは？？
というわけで、こんな私のような「これから副業パーソンズ」に向けてアドバイスをくれ。ください。
私が聞きたいことは以下のとおりだ。
とまぁこんな感じ。叡智よ集えー。
男も女も、類似性で仲間を形成する。男の場合、概ね以下のカテゴリになる。
1.スポーツが出来る奴
2.ガリ勉
4.無能
5.何考えてるかわからん奴
スポーツ、ガリ勉、オタク、無能の順番でモテる。高知能集団だと社会で活躍できる要素がモテに反映されてガリ勉の方がモテることもある。
上位の序列と親しいことは喜びで、
下位の序列と親しいことは汚点となる。
この軸を基本に、暴力性が掛け算される。暴力性とは、態度の大きさとそれを正当化する筋力、身長、武術、人脈を示す。人脈とは、主に不良コミュニティとの交わりを指す。
暴力性が高いと、序列が上がる。序列が上がる理由は、モテるからだ。
なぜ母親が男の育てをしてはいけないかと言うと、母親には暴力性の概念がわからないから。
将来のために沢山お勉強してほしい、優しい子に育ってほしい。
これは同性に対するベストプラクティスであり、男子学生にとっては舐められ要素だ。
小さいうちに同性から舐められると、学校での活動が大きく制限される。自分の意見を伝えて、受け入れられる確率が下がる。
学校の活動で成功体験を得るためには、意見を通すための裏打ち、つまりモテ要素、スポーツ、身長、筋力を養って行く必要がある。
お母さん方は、自分が若い頃に感じたトキメキ、強くて怖い男に対する妙な安心感や頼りがい、
これを思い出すべきだな。
そして、息子にもそういった要素がないと、
クラスの端っこで勉強して、話も面白くない、とにかく関わる価値のないのない陰キャ扱いされてしまう。
そこを考えてあげた方がいいな。
ワイも最初これがわかってなかった。らだが息子の学校の男子らの喧嘩や力関係を大概試合や行事の観察で理解した。男社会は力が支配する。力がなければダメだ。
それは父親がルールを教えなければならない。女にはわからぬ世界だよ。
だからワイは一歩引いている。母やが細かく世話を焼くのもダメだ
男社会のルールを知らないから。うちの婆さんはシンママだったから叔父さんも苦労したらしい。女所帯は近所からも舐められて石を投げられバカにされまくった。
単に力って言うとあんまり面白くないんですどね。男社会には男社会のエレガンスもあるんですよ。
紳士協定みたいのがある。
男は敵にも加減する。敵も友になる。
女はそれがない。手心を加えない。加減がわからないから叩きのめしてしまう。
たまたまコードの3つの部分について、共通性があったとして、この共通性を一般化してライブラリ化し、再利用可能にしたとする。
一見すると良いプラクティスに思えるが、文脈次第では痛手を追う。
この「共通性」が、今後未来に渡ってずっと続くとは限らない。たまたま現時点において一般化できると言うだけで、未来では3つの部分が別々の機能性を持つことも考えられる。
そのときに再利用可能なライブラリとして作ったことを後悔することになる。別々なら影響を限定して作れたのに、ライブラリにするといちいち手間がかかる。
