2024-04-26

2024/04/20-2024/04/26

DevOpsに興味が出た

DevOpsに興味が出た。というか、DevOpsエンジニアとして舵を切っていこうかなと思っている。理由は以下。

　- 機能の変更や、機能の追加のリードタイムを減らしたい。

　現在、受託開発をしているが、機能の変更や追加の相談を受けて、見積もりを出した時に、工数の兼ね合いで、発注に至らないケースが多い。

　　会社としても損失だし、エンジニアとしてより良いものを作りたいと思っているので、システムを良くしていくようにできないのは歯がゆい。

　　機能の変更や追加を容易にできるようにすることで、三方よしになるのではないか？

　　・自社：発注を受けて売上アップ

　　・取引先：システムが良くなることで、サービスの質が上がり、顧客の増加、定着

　　・ユーザー：システムが良くなることで、満足度の増加

　- 個人的には、実際に動くものを作れる実装が好き。パズルを解いている感覚に近く、論理的な推測をしつつ、意図した通りのものを作れた時の達成感がやりがい。また、変更しやすく、意図の分かりやすいコードや、パフォーマンスのいいコードをかけた時も同様。

　ではあるが、キャリアアップを考えると、どうも実装に比重を置くのは難しそう。

　日本のIT業界では、キャリアアップ = マネジメントというモデルが多い。

　確かに、レバレッジをかけるという意味では、作業スキルを極めるより、マネージメントスキルを極める方がいいとはおもう。一人より多人数の方が出力は高いので、理には適っている。

　ただ、人の調整、スケジュール管理、顧客折衝などを主にするよりは、開発に携わっていたいので、開発だけではなく、運用面のスキルも磨けば、開発側でポジションを見つけれるのではないか？

DevOpsの勉強を始めた

・手始めに、AWS Certified DevOps Engineer - Professionalを勉強しようかなと思っている

・第一歩として、AWS Certified Cloud Practitionerを勉強中

・あとオライリーの以下の本を買って読む予定

　・O'Reilly Japan - 入門継続的デリバリー

　・O'Reilly Japan - オブザーバビリティ・エンジニアリング

　・O'Reilly Japan - SLO サービスレベル目標

　・O'Reilly Japan - ソフトウェアアーキテクチャメトリクス

　・O'Reilly Japan - システム運用アンチパターン

　＜以下はできれば読みたい＞

　・O'Reilly Japan - 入門監視

　・O'Reilly Japan - ソフトウェアアーキテクチャの基礎

　・O'Reilly Japan - ソフトウェア設計のトレードオフと誤り

　・O'Reilly Japan - オブジェクト設計スタイルガイド

　・O'Reilly Japan - データ保護完全ガイド

マインドの変化

　モデルがありそれを真似る、先導者がいて導いてもらうという思考より、自ら学びつつ、自分で考えてどうすればいいか、自分が主体となって決める。受身的な仕事ではなく、主体的な仕事。言われたからやるではなく、こちらが言って周りを巻き込む。

こんな感じに変化した。

Next.jsの勉強

　参考書を購入　

　・Nextのルーティングを学んだ（AppRouter、useRouterを使う）
　・Nextのレンダリングを学んだ（Server側とクライアント側でレンダリングする）

　・NextのAPIの実装方法

　・Prisma

　・NextでAPIを実装できるなら、Expressは必要ない？

　　Nextでフロントとバックを一つにして開発することと、

　　Nextでフロント、バックをNextかExpressで分けて開発することの違いを知りたい

　　参考記事が下記にあった。

フロントエンドとバックエンドを分けた開発について

Youtubeで見たプロゲーマーの話がかなりいい話だった

www.youtube.com

暗記型と法則型として語られているが別の言葉の方が良いのでは？と思ったので、以下として定義する。

暗記型：模倣型

法則型：追求型

それぞれの特徴

模倣型：サンプルや参考書を見て、要点を掴み、すぐに実行できる
追求型：いろんな疑問を持ち、深く追求することで技術が身につく

エンジニアで例える

模倣型：How to系の記事や、チュートリル型の記事、エラーに対する解決方法だけの記事で、とりあえず動かせる状態に持っていく

追求型：公式ドキュメントなどを読み、仕組みから理解していくのが追求型

動画でも語られているが、どちらも一長一短。

模倣型のメリット　：実行して結果が得られるまでが早い

模倣型のデメリット：深い理解はないので、関連した問題の対処や応用ができない

追求型のメリット　：深い理解があるので、関連した問題の対処や応用が効く

追求型のデメリット：理解に時間をかける（かかる）ので、実行して結果が得られるまでが遅い

エンジニアとしては、なるべく追求型のスタンスでいた方が良いと思う。

世界一流エンジニアの思考法で、

マイクロソフトに勤める優秀なエンジニアが難しいことを理解していて、著者が「難しいことを理解してすごいなー。頭がいいんだろうな」と思っていたところ、その優秀なエンジニアはそれを理解するために、何回も繰り返し時間をかけたという話があった。

優秀な一流のエンジニアでさえ、理解するには時間をかける。

理解に時間をかけず、表面上の理解だけで仕事をしていると、作業スピードは確かにはやいし、評価もされるかもしれない。

でも、何も身についてないので、次同じことをするときにまた調べ直したり、ちょっとしたトラブルや、よくドキュメントを読んでいたら回避できたことにつまづくこともある。

なので、時間の許す限りは時間をかけて、基礎から理解していくようにした方がいい。

新しい技術や、エラーの解決など調べるときは、人に説明できるくらい、場合によっては記事を書いたりしながら深く理解することを習慣にした方が最終的にはよさそう。

2024-04-19

2024/04/12 - 2023/04/19

・転職活動のための面談を受けた

・Flutterのパッケージをアップデートすると、あるパッケージでJava17が求められた。
インストールしているJavaのバージョンを上げたが、flutter doctor -vで確認するとJavaが11のままでビルドエラーが解消しないという現象にハマった。

詳細は記事にした。

・マイホームを買おうと思っているが、ローンだったり、どういう物件がいいのか勉強中。物件のチェックポイント、間取り、ローン、注文住宅、建売、建築条件付き、マンション。そもそも、賃貸がいいのか買った方がいいのか勉強中。
・FP3級のテキストを買って、読んでいる。

・FRPの本を買ったので読書中

・パスを通すことについて調べた

・シンボリックリンクについて調べた

・Crashlyticsの送信方法について調べた

2024-04-16

202404/6 - 2024/04/12の振り返り

202404/6 - 2024/04/12

・Firebase Crashlyticsの実装方法を調べた。解析方法や、どのように使っていけば、アプリの不具合解析、安定運用に繋がるかも調べたい。

・LeetCodeの問題を解いた

・DB設計の本を読み進めた。読んだ本は、達人に学ぶDB設計。設計のアンチパターンや、DBのパフォーマンス改善について知ることができた。パフォーマンスについては、もう少し深い理解がしたいと思った。また、設計書のフォーマットについては書いてなかったので、別途調べたい。この記事が良さそう？

・プライバシーマニフェスト対応でFlutterを3.19.5にアップデートした際、--dart-define-from-fileの変数がbuild.gradle内で使えなくなったので、たいしょ。ビルドの構成についてドキュメントを読んで理解した。
https://docs.flutter.dev/deployment/android#reviewing-the-gradle-build-configuration