Open67

IDEA集

まさきちまさきち

ローカルIPアドレス確認方法

ifconfig | grep "inet " | grep -v 127.0.0.1

ifconfigの出力からIPv4アドレスを抽出し、127.0.0.1(localhost)を除外。

  • 127.0.0.1(localhost)は、コンピュータの内部通信のためのIPアドレス。このアドレスをターゲットにすると、通信は外部には行かず、自分自身に戻る。これは、ネットワーク機器や外部のサービスなど、外部のリソースには影響を与えることなく、ネットワーク関連のテストやデバッグを行うために役立つ。
まさきちまさきち

git clone --recursive について

Gitリポジトリをクローンする際に、そのリポジトリがサブモジュールを含む場合、サブモジュールの内容も同時にクローンするためのオプション。
Gitには「サブモジュール」という機能があり、あるリポジトリ内に別のリポジトリをサブディレクトリとして組み込むことが可能。
git clone コマンドだけでは、サブディレクトリの内容は取り込まれない。

まさきちまさきち

Next リクルート新人研修

https://speakerdeck.com/recruitengineers/next-dot-js-26c1e15f-1514-4646-b6b8-cbf80f8d10ed


Next.jsのパフォーマンス

  • ページ単位で必要最低限のチャンクファイルが分割出力される。新規機能を追加しても、既存ページの初期動作は遅くならない。
    (古典的なSPAはチャンクファイルを分割せず、単一のHTMLファイル・JavaScriptバンドルをレスポンスする)

※ ブラウザに送信するJavaScriptバンドルサイズはパフォーマンスに直結しており、next.jsに限らず、JavaScriptバンドルサイズを削減することが求められる。(React 18で追加された、server componentsはバンドルサイズの削減に繋がる)

  • 事前レンダリング:リクエスト発生前に事前にページをレンダリングしておく
まさきちまさきち

お給与・評価 → 一人称開発・メンタルケア・追加Valueを出してもらう
K:keep = 良かったこと
(今後も続けること、顧客や周りの人に「褒めて」もらったこと、発揮した価値や、改善から成果につながったこと)
P:problem= 悪かったこと(今後はやめること)
T:try = 次に挑戦すること(解決策、具体的な行動に落とし込む)

https://miro.com/miroverse/kpt-japanese/

https://www.notion.so/ja-jp/templates/kpt

まさきちまさきち

キャッチアップ速度が速い人の特徴

キャッチアップは小さい学びの集合体であり、一つのやり方にこだわるとそれ以外の効率が悪くなる。
学び方が多様な場合、それぞれの学びが相互作用して連鎖的に学びの速度が上がる(自分はこのようなタイプだと決めない方が良い)。

キャッチアップの手段は様々

  • 本を読む、人に聞く、やり方を真似る(盗む)、怒られて反省する、振り返り・KPT、FBをもらう
  • 学ぶための「やり方」に得意不得意を持たないこと。

EX)

  • 人のコードの良い実装や設計をパクる。
  • 他の人の思考回路を想像する。
  • レビュー、ペアプロを行う。
  • 手を動かして技術の手触り、技術の感覚を掴む。
  • 設計など自身で悩む。
  • 実装のデザインパターンなど先人の技術を学ぶ。

https://speakerdeck.com/nrryuya/kiyatutiatuhusu-du-kasu-i-number-toha

まさきちまさきち

UIの考慮すべき5つの状態

5つの状態
・Blank State(空っぽの状態)
 → ユーザーが初めてサービスを使うときに見られる状態
 → 情報が未登録であること、どこでどうやったら登録できるかを提示する。
・Loading State(ローディング状態)
 →データを読み込んでいるとき。
 → 待っていれば表示されることをユーザーに伝える(ロード中何も表示されないと、直前に行ったアクションが本当に実行されてるのかユーザーは不安になってしまう)
・Partial State(部分達成状態)
 → サービス利用を継続してIdeal State(理想状態)を目指してもらう

・Error State(エラー状態)
 →エラーです!という言いっぱなしはNG(ユーザーにどうするべきか伝える。)
・Ideal State(理想状態)

https://note.com/kana_cbr250r/n/n231966c2555d

まさきちまさきち

続けるために必要なのは才能ではなく、この仕事続けたいかどうか の意志である。
今更たらればを言っても仕方ない。

確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当時の自分は才能が無かったとして、でもソフトウェアエンジニアを続けたいっていう想いがあった。

マネージャーの才能が無い、経営者の才能が無い、自分にはこれは向いていない。でも結局向いていないからやらない、のではなく 必要だからやる って姿勢が仕事を進めていく。 例えばもう自分はCTOになっている。 CTOとしての才能があろうがなかろうが、もうやっていくしかない。

https://soudai.hatenablog.com/entry/2024/03/05/120426

まさきちまさきち

自分は思ったほど頭が良くなかった話

私と彼を比較すれば、私は信念に欠如しており、彼は信念にあふれているということです。遺伝子の偶然などということではなく。
「頭がよい」というのは単に、「とても多くの時間と汗を費やしたので、難なくやっているようにみえるまでになった」ということを言い換えているに過ぎない
彼のことを知るにつけ分かったことは、彼の知性と実績のほとんどは、まさに勉強と鍛錬によってもたらされているということでした。そして、必要に応じて学んで訓練をした知性の道具や数学の道具を蓄積した結果として、彼の大きな道具箱があるのだと知りました。彼はそれらの道具をいくつか見せてくれましたが、私にとっての本当の収穫は、自分独自の道具をどうやって探して、つくって、改良するかという方法を理解したことでした。

https://b.log456.com/entry/20120110/p1

まさきちまさきち

ヒープ領域制限によりnode.jsのビルドが通らない

npm run build
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

ビルドするためのエラーが通らないと怒られる。
スワップ領域を確保する必要がある。
スワップ・・・使っていないメモリの内容を一時的にしまっておくための場所(ハードディスクにてメモリっぽく使うことで、実際のメモリより大きなメモリがあると錯覚させる)

export NODE_OPTIONS="--max-old-space-size=1024"
または node --max-old-space-size=1024 $(which npm) install
npm run build

https://qiita.com/nakamto/items/8ed18f9f0d980fd70be1

まさきちまさきち

EC2環境とローカル環境のファイル差分ではまった話

EC2環境でnpm run buildを実施したところ以下のエラーが発生

WARNING in ./src/store/Lists/Main/state.ts
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:

このエラーは大文字小文字を区別するファイルシステムでの名前の衝突に起因している。ローカル環境ではnpm run buildを実施しても上記エラーが発生しないがこれはWindows環境や一部のmacOSの設定により、ファイルの大文字小文字を区別しないため。Linuxを含む多くのUNIX系オペレーティングシステムでは、大文字小文字を区別する。

gitリポジトリを確認すると大文字小文字が異なるファイルが存在することを確認。


対応策

  1. Gitの大文字小文字の扱いを確認する
    Gitはデフォルトでファイル名の大文字小文字の違いを認識するように設定する。
git config core.ignorecase false
  1. 不要なフォルダを削除する。
    it rmを使うと、指定したファイルが完全に削除されるので、リポジトリだけではなく、ワークツリーからも削除される。
git rm -r checklists
git commit -m "Remove duplicated folder"
  1. Gitのキャッシュをクリアする。
git rm -r --cached .
git add .
git commit -m "Reset git cache"
まさきちまさきち

ref VS reactive

結論:「迷ってるならとりあえず ref を使っておけばいい」

https://zenn.dev/comm_vue_nuxt/articles/ref-vs-reactive#reactive-は通常のオブジェクトと判別しづらい

理由:

  • reactive は通常のオブジェクトと判別しづらい
  • reactive はオブジェクト型(オブジェクト、配列、および Map や Set などの コレクション型)に対してのみ機能し、文字列、数値、真偽値などの プリミティブ型 を保持できない。
  • reactive はオブジェクト全体を置換できない。
  • reactive は分割代入できない。

https://ja.vuejs.org/guide/essentials/reactivity-fundamentals#limitations-of-reactive

ref はネストしたオブジェクトもリアクティブにすることが可能(内部で reactive が呼ばれるだけである為)。

まさきちまさきち

つよつよエンジニア 成果物の特徴

https://qiita.com/lazy-kz/items/727299cae893ab3442a0


詳細

  1. 非機能要件が考慮されている
    → セキュリティやユーザビリティ、保守性、可読性、拡張性、パフォーマンス、テスト性、例外処理といった非機能要件が考慮された実装になっている(これらの要素は要件定義書や開発チケット上に書かれていることは少ない要素ではあるものの、高いユーザー体験や安定的なサービス運営には欠かせないも)


  1. プログラミングの原理原則が守られている
    → SOLID原則やUNIX思想、DRY原則、KISS原則、YAGNI原則、OAOO原則といったプログラミングの原理原則が守られている。 = 「シンプルで美しいコード」


  1. リポジトリ内に無駄なものが無い
    コメントアウトされているコードはすぐ削除する。デッドコードや.DS_Store などの不要なファイルがリポジトリにコミットされたとしてもつよつよエンジニアは発見次第除去していくので、リポジトリ内は綺麗な状態に保たれる傾向にある。


  1. CI/CD pipelineが初期から整備されている
    自動化は必須


  1. テストコードが(高確率で)存在する



つよつよエンジニアの条件

  1. プログラミング言語、原理原則論、セキュリティ/ネットワーク等の周辺領域の勉強
      非機能要件をカバーしつつ綺麗なコードを書くために必要
  2. 最先端の技術スタックの勉強
  3. 自身が開発するサービスのドメインに関する勉強
     高いユーザー体験を持ったサービスを作るうえで必須。
     ドメイン知識が無いとエンドユーザーにとって使いやすいものは作れない。
  4. 組織マネジメントに関する勉強
  5. 法務/労務/財務/経理といったビジネス領域の勉強
      取締役/執行役員 CTOのような技術系経営層になるうえで必須。
      これらの基礎知識がないと他のボードメンバーと経営課題の議論ができない。