IDEA集
英語記事読書方法
プログラミングの変数・メソッドの命名でよく使う英単語まとめ
エンジニアの劣等感との付き合い方
初めから強いやつの特徴
オススメ Youtubeチャンネル
キャッシュ戦略について
設計書を書くコツ
ドメイン駆動設計(DDD)
Reactベストプラクティス
フロントエンド News
ローカル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 リクルート新人研修
Next.jsのパフォーマンス
- ページ単位で必要最低限のチャンクファイルが分割出力される。新規機能を追加しても、既存ページの初期動作は遅くならない。
(古典的なSPAはチャンクファイルを分割せず、単一のHTMLファイル・JavaScriptバンドルをレスポンスする)
※ ブラウザに送信するJavaScriptバンドルサイズはパフォーマンスに直結しており、next.jsに限らず、JavaScriptバンドルサイズを削減することが求められる。(React 18で追加された、server componentsはバンドルサイズの削減に繋がる)
- 事前レンダリング:リクエスト発生前に事前にページをレンダリングしておく
CommonJSとES Modulesについて
npmの依存関係について
IT media
N + 1問題
社内を巻き込むために大切な10のルール
Vite VS webpack
シェルについて
svh・dvh
お給与・評価 → 一人称開発・メンタルケア・追加Valueを出してもらう
K:keep = 良かったこと
(今後も続けること、顧客や周りの人に「褒めて」もらったこと、発揮した価値や、改善から成果につながったこと)
P:problem= 悪かったこと(今後はやめること)
T:try = 次に挑戦すること(解決策、具体的な行動に落とし込む)
シェルスクリプト
1on1で質問をする側になって「工夫したこと」と「気づいたこと」
ログの基本
git revertについて
ブラウザの内部構造について理解する
コードテスト
Front-end Frameworks
CodeRabbit
初回レビューをAIに任せる(Github Actionに設定を追加する)
OAuth2.0
SQL アンチパターン
設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選
NewsPick エンジニアの採用基準
- 採用基準の明確化
- 自社の魅力の明文化
- 採用ポートフォリオの作成
画像は基本的にライブラリを使用してEXIF情報を削除する。
MACでパスワード付きzipファイルを生成する方法
zip-e -rコマンドを使用する
zsh設定
zsh-autosuggestionsの導入
ohmyzshの導入
アルゴリズム
アルゴリズム入門
キャッチアップ速度が速い人の特徴
キャッチアップは小さい学びの集合体であり、一つのやり方にこだわるとそれ以外の効率が悪くなる。
学び方が多様な場合、それぞれの学びが相互作用して連鎖的に学びの速度が上がる(自分はこのようなタイプだと決めない方が良い)。
キャッチアップの手段は様々
- 本を読む、人に聞く、やり方を真似る(盗む)、怒られて反省する、振り返り・KPT、FBをもらう
- 学ぶための「やり方」に得意不得意を持たないこと。
EX)
- 人のコードの良い実装や設計をパクる。
- 他の人の思考回路を想像する。
- レビュー、ペアプロを行う。
- 手を動かして技術の手触り、技術の感覚を掴む。
- 設計など自身で悩む。
- 実装のデザインパターンなど先人の技術を学ぶ。
UI Pocket
UIの考慮すべき5つの状態
5つの状態
・Blank State(空っぽの状態)
→ ユーザーが初めてサービスを使うときに見られる状態
→ 情報が未登録であること、どこでどうやったら登録できるかを提示する。
・Loading State(ローディング状態)
→データを読み込んでいるとき。
→ 待っていれば表示されることをユーザーに伝える(ロード中何も表示されないと、直前に行ったアクションが本当に実行されてるのかユーザーは不安になってしまう)
・Partial State(部分達成状態)
→ サービス利用を継続してIdeal State(理想状態)を目指してもらう
・Error State(エラー状態)
→エラーです!という言いっぱなしはNG(ユーザーにどうするべきか伝える。)
・Ideal State(理想状態)
おしゃれリポジトリ駆動開発
Date formkit
HTML5 入れ子チートシート
続けるために必要なのは才能ではなく、この仕事続けたいかどうか の意志である。
今更たらればを言っても仕方ない。
確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当時の自分は才能が無かったとして、でもソフトウェアエンジニアを続けたいっていう想いがあった。
マネージャーの才能が無い、経営者の才能が無い、自分にはこれは向いていない。でも結局向いていないからやらない、のではなく 必要だからやる って姿勢が仕事を進めていく。 例えばもう自分はCTOになっている。 CTOとしての才能があろうがなかろうが、もうやっていくしかない。
自分は思ったほど頭が良くなかった話
私と彼を比較すれば、私は信念に欠如しており、彼は信念にあふれているということです。遺伝子の偶然などということではなく。
「頭がよい」というのは単に、「とても多くの時間と汗を費やしたので、難なくやっているようにみえるまでになった」ということを言い換えているに過ぎない
彼のことを知るにつけ分かったことは、彼の知性と実績のほとんどは、まさに勉強と鍛錬によってもたらされているということでした。そして、必要に応じて学んで訓練をした知性の道具や数学の道具を蓄積した結果として、彼の大きな道具箱があるのだと知りました。彼はそれらの道具をいくつか見せてくれましたが、私にとっての本当の収穫は、自分独自の道具をどうやって探して、つくって、改良するかという方法を理解したことでした。
ヒープ領域制限により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
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リポジトリを確認すると大文字小文字が異なるファイルが存在することを確認。
対応策
- Gitの大文字小文字の扱いを確認する
Gitはデフォルトでファイル名の大文字小文字の違いを認識するように設定する。
git config core.ignorecase false
- 不要なフォルダを削除する。
it rmを使うと、指定したファイルが完全に削除されるので、リポジトリだけではなく、ワークツリーからも削除される。
git rm -r checklists
git commit -m "Remove duplicated folder"
- Gitのキャッシュをクリアする。
git rm -r --cached .
git add .
git commit -m "Reset git cache"
ref VS reactive
結論:「迷ってるならとりあえず ref を使っておけばいい」
理由:
- reactive は通常のオブジェクトと判別しづらい
- reactive はオブジェクト型(オブジェクト、配列、および Map や Set などの コレクション型)に対してのみ機能し、文字列、数値、真偽値などの プリミティブ型 を保持できない。
- reactive はオブジェクト全体を置換できない。
- reactive は分割代入できない。
ref はネストしたオブジェクトもリアクティブにすることが可能(内部で reactive が呼ばれるだけである為)。
AWS Certified Cloud Practitioner
aws-cloud-quest
つよつよエンジニア 成果物の特徴
詳細
- 非機能要件が考慮されている
→ セキュリティやユーザビリティ、保守性、可読性、拡張性、パフォーマンス、テスト性、例外処理といった非機能要件が考慮された実装になっている(これらの要素は要件定義書や開発チケット上に書かれていることは少ない要素ではあるものの、高いユーザー体験や安定的なサービス運営には欠かせないも)
- プログラミングの原理原則が守られている
→ SOLID原則やUNIX思想、DRY原則、KISS原則、YAGNI原則、OAOO原則といったプログラミングの原理原則が守られている。 = 「シンプルで美しいコード」
- リポジトリ内に無駄なものが無い
コメントアウトされているコードはすぐ削除する。デッドコードや.DS_Store などの不要なファイルがリポジトリにコミットされたとしてもつよつよエンジニアは発見次第除去していくので、リポジトリ内は綺麗な状態に保たれる傾向にある。
- CI/CD pipelineが初期から整備されている
自動化は必須
- テストコードが(高確率で)存在する
つよつよエンジニアの条件
- プログラミング言語、原理原則論、セキュリティ/ネットワーク等の周辺領域の勉強
非機能要件をカバーしつつ綺麗なコードを書くために必要 - 最先端の技術スタックの勉強
- 自身が開発するサービスのドメインに関する勉強
高いユーザー体験を持ったサービスを作るうえで必須。
ドメイン知識が無いとエンドユーザーにとって使いやすいものは作れない。 - 組織マネジメントに関する勉強
- 法務/労務/財務/経理といったビジネス領域の勉強
取締役/執行役員 CTOのような技術系経営層になるうえで必須。
これらの基礎知識がないと他のボードメンバーと経営課題の議論ができない。
テキストの折り返しについて、overflow-wrap: anywhere;とoverflow-wrap: break-word;の場合、overflow-wrap: break-word;
を指定した方が良さそう。