この記事は以下の取り組みに沿ったものです。
My Journey Through daily.dev - Beginning 2024-W07
ToC
⚡️Highlights
- htmx
- 良いREADME.mdの書き方
- Productivityを下げるもの・高めるもの
- Tauri
- GitOps
- ジュニア開発者に言ってはいけない10のこと
- Programmer’s Tips
🌞Sunday
The Front-End Development we’re used to is dying - DEV Community
📝 Summary
- フロントエンド開発で死につつあるもの
- SPAが誕生する前はWEBアプリケーションはユーザー操作のたびに毎回リロードされるMPAだった。
- MPAからSPAに移り、シンプルだったことを複雑にし始めた
- htmxの登場により、基本的な知識があるバックエンド開発者なら少しのロジックでSPAなWEBアプリを開発できるようになった。
- フロントエンド開発にはJavaScriptのロジックだけではなくCSSやHTMLも必要だが、AIやHTMLレイアウトデザイナーがFigmaのレイアウトを元にテンプレートを生成できるようになった。
- 高度なフロントエンド開発ツールが必要なのか純粋なフロントエンド開発者で居続けるのかを考えるいい機会である。
🤔💭 My Thoughts
- Upvoteが49個ついている記事。日本以外でもフロントエンド関連の記事は人気があるというか注目されやすいのかも。
- 今に始まったことではないが、最近のフロントエンド開発が複雑なのは自分も感じていた。( 自分が純粋なフロントエンド開発者ではないのもあるが )
- htmxは、Xで流れてきたことがあるが読み飛ばしていた。キャッチアップしよう。
- バックエンド開発の延長でSPAを開発できるとしたら開発がかなり楽になりそう。
- フロントエンド開発者がHTMX開発者みたいに複雑なエコシステムにならなければいいけど。
- AnalogというAngularベースの meta-framework ? があるらしい。meta-frameworkって何だ？
- Analog | Analog
- Astroみたいなやつっぽい ( Introduction | Analog )
🌝Monday
How to create a good README.md file - DEV Community
📝 Summary
- 良いREADMEの書き方について
- READMEを読むのはリクルーターや将来の上司や顧客である
- 最も重要なこと
- プロジェクトの説明
- 使用している技術スタック
- プロジェクト自体についてだけではなく、ドキュメンテーションスキルも見られている
- READMEに含めるもの
- 何についてのプロジェクトなのか？
- なぜそのプロジェクトを開発しているのか？
- どんな問題を解決するものなのか？
- 何を学んだのか？
- そのプロジェクトの傑出した点は何？
- Markdownの書き方についての説明
🤔💭 My Thoughts
- ポートフォリオとしての書き方に焦点を当てた記事
- OSS系のREADMEしか読んだことがないから、想定読者がリクルーターなのは新鮮
- 自分のGitHubリポジトリもトイアプリなどばかりで1つのものとして完成したものがないから、何か1つ作りきりたいな
🔥Tuesday
Productivity killers and boosters for software engineers - ShiftMag
📝 Summary
- 生産性を下げるものと高めるものについて
- 下げるもの
- Procrastination : 先延ばし
- 面白くないタスクもやるしかない。やってみたら思っているより簡単に終わる。
- Interruptions and Distractions : 中断と注意散漫
- スマホは視界に入らないようにし、手も届かないようにする
- もし電話に出損ねてもあとで掛け直せば良い。
- これだけで私の中断は90%解決した。
- 通知も大きな中断要因である
- Slackなどのコミュニケーションツールは設定を工夫する
- 入る必要のないチャンネルは抜ける、ミュートする
- 必要ならメンションされるはず
- SNSも通知が多いが、スマホは見えないところにあるので解決される
- Slackなどのコミュニケーションツールは設定を工夫する
- スマホは視界に入らないようにし、手も届かないようにする
- Unexpected issues : 予期せぬ問題
- 同僚から協力の依頼が来る。助けるのももちろん義務だが自分仕事のための時間も必要
- 手伝えない状況ならそれをはっきり伝えるべき。
- 自分の仕事が終わったら助けが必要かを聞き直せば良い。
- 同僚から協力の依頼が来る。助けるのももちろん義務だが自分仕事のための時間も必要
- Procrastination : 先延ばし
- 高めるもの
- 自分に適した日々のルーチン
- 最も重要な要素
- ピカソやベンジャミン・フランクリン、ベートーヴェンのルーチンが紹介されている
- 短い休憩を取る
- ツールとショートカット
- 自分に適した日々のルーチン
- 友人の1人は起きた後、コーヒーも飲まずスマホも見ずに、真っ直ぐベッドからノートパソコンに向かって仕事を始める
- 友人は私たちの頭はRAMだと言っている。
- 起きた時は空で、その日、見たり、聞いたり、感じたり、したりすると埋まっていく
- 短い休憩を取る際は、椅子から立ち上がってゴミを捨てたり、お皿を洗ったりする
- そうすることでリフレッシュされてより集中できる。
- キーボードショートカット
- 便利なツール
- Rocket
- Obsidian
- Maccy
- Lightshot
- BitWarden
- Excalidraw
🤔💭 My Thoughts
- 記事とは直接関係ないけど、ポートフォリオサイトに使っているデバイスやツールを記載しているのがよい
- 日本も海外も困っていることは変わらない。
🐳Wednesday
Goodbye Electron. Hello Tauri! - DEV Community
📝 Summary
- [[Electron]]の欠点の1つがバイナリサイズが大きすぎること
- それを解決するのがRust製フレームワークの[[Tauri]]
- Electronを追い抜くほどの成長性があると感じている
🤔💭 My Thoughts
- ElectronやIonicなどのGUi Frameworkは存在は知っているけど使ったことはない。
- フロントエンド周りのツールチェインやエコシステムにRustが採用されることがかなり多い。
- GUI Frameworkの情報を追うことは少ないと思うけど、Electron一択ではないじょうきょうになりつつある、ということは覚えておこう。
🌲Thursday
📝 Summary
- [[GitOps]]とはインフラストラクチャーをバージョン管理すること
- DevOpsチームが担当する
- GitOpsのワークフローを構築しメンテナンスする責任を持つ
- Developerはコードや設定変更をコミットすることで、アプリのデプロイや運用を直接変更できる
- なぜ2024年にGitOpsなのか？
- コミット履歴
- ミスを減らす
- 変更の自動適用
- 環境とリポジトリが同期されている
- GitOpsの主要ツール
- [[Argo CD]]
- [[Flux]]
- [[Terraform]]
🤔💭 My Thoughts
- AWSのCloudFormationにもGit Syncって機能があるけどGitOpsをするためのもの
- Kubenetesを前提にして紹介されている。Kubenetes全然知らないんだよなぁ。
- 実際の業務でこの記事レベルのGitOpsを実践し始めるのはかなり根気がいりそう。
- 自分のキャリアをDevOpsエンジニアに向けていく意志がないと学習するモチベも上がらない。
- (メタ) DevOps系の記事はあんまり読まないでいいかも。今はもっとアプリ開発よりの記事の方が興味がある。明日は何を読もうかな。
⚜️Friday
10 Things You Should Never Say to Junior Developers - DEV Community
📝 Summary
ジュニア開発者に言ってはいけない10のこと
- これは簡単だよ、難しくないよ
- これはすでに知っているべき、自分で解決すべき、なぜまだ理解できないの？
- どうやったらこんなミスをするの？、私ならこうしない
- 時間がかかりすぎだ、私ならもっと早い、あなたに説明する時間はない
- こうするだけだ、ここではそういうやり方はしない
- 新米すぎる、ただのジュニア開発者だ、もっと経験がないと理解できない
- ここにいるだけでラッキーだね
- 馬鹿げた質問だ
- 本物のプログラマーならしない、現実世界ではそうしない
🤔💭 My Thoughts
- どうでもいいけど、10個ではなく9個しかない
- 経験豊富なエンジニアではないけど、同僚のエンジニアについ言ってしまっている言葉がある
- これは簡単ですよ、とか
- それ以外の言葉は流石に使ったことがない
🪐Saturday
100 Tips from The Pragmatic Programmers Book: Part 4/10 - DEV Community
📝 Summary
- 全10記事あるうちの4つ目の記事
- 4.1. コードを修正する前にテストを失敗させる
- 4.2. エラーメッセージを読む
- 4.3. 選んだものは壊れていない ( OS、コンパイラ、ライブラリではなくアプリが壊れていることがほとんど )
- 4.4. 決めつけるのではなく、証明する
- 4.5. テキストを操作する言語を学ぶ ( awk, sed, perlのことかな？ )
- テキスト操作言語とは？ : Category:Text-oriented programming languages - Wikipedia
- 4.6. 完璧なソフトウェアは書けない
- 4.7. 契約による設計
- 4.8. 早めにクラッシュする
- 4.9. アサーションで不可能なことを防ぐ
- 4.10. 始めたものが終わらせる ( リソース生成と破棄の話 )
🤔💭 My Thoughts
- 本からの引用を抽象化してタイトルをつけている記事
- 各タイトルと引用を読んでも具体的な内容はイメージできないから原著を読む必要がある
- ネイティブではないせいか、引用元の文章からタイトルへの関連がイメージできない…
🪄Reflection
このブログテーマの目的は英語学習(技術キャッチアップはおまけ)だけど、記事を選ぶ際の基準は明確にしておいたほうがよさそう。 毎日daily.devを見て直感で記事を選んでいるけど時間がかかることもあって少しストレス。 読んでいる途中や読んだ後に、この記事は今の自分にマッチしていないと思うこともある。
そう考えると、目指すキャリアを明確にして、キャリア形成を後押しするためのサイドプロジェクトを立ち上げて、それに関わる記事を読んでいくようにしたほうが生産性が高そう。
あと、まずは原文を読むようにしているけど、気軽に翻訳ツールに頼りすぎている。 始めたばかりの取組みだから、今は厳密にし過ぎないようにしてるけど、慣れてきたら自分に制約を課して、自力で和訳するようにしていきたい。
まずは、わからなかった単語をこのブログに残してもいいかも。( 復習用にAnki化するとかも。 )
とりあえず、最初の1週間は何とかやり遂げれた。来週も頑張ろう。