記事を書くことに意味を感じなくなったのと色々考えた
2023年になったので、今ままでのことを振り返る
今日は、普段の仕事とか僕の最近の悩みを言語化しようと思いました。
そもそも僕は、国語が弱いので、言語化
って言葉も去年知りました。
普段から、Flutterのアウトプットを続けて、Zennの記事をいっぱい書きました。しかし、それをやったからといって僕の評価が変わることはなかった…
最近無駄だから、全部記事を消そうとも思った。記事書いても僕のスキルが伸びていたわけではない。中身がないと思う人もいるから、それ感じて記事を書くのをやめようかな〜と思いつつもついつい書いてしまう。
最近の楽しみは、普段やらないビジネスロジックを書いたり、他の言語で書いているコードをDartで書くことですかね。Dartで書いてるのをSwift、Kotlinで書いたりもします。
🗒️そもそも何で記事を書くのを始めた?
元々、Qiitaで記事を書いてました。でも、Zennの方がカッコいいな〜って思って書き始めたのが始まり。
Flutterのコミュニティで2年以上アウトプットを続けてきたけど、最近無駄だと感じるようになってきた。ネットの噂を聞けば、Flutterの仕事少ないとか、「動きがぬる〜としてる」とか言われて、Nativeで作った方がいいとか聞くようになりました。
Xでたまに話す知り合いの子も最近仕事がないと言っていた???。これには理由があると思いますけどね。
☠️仕事を紹介してもらったときの悩み
普段使わない文法を使ったりやすぐに進捗を出すのを要求されてストレスだった…
設計書もない、要件定義もないそんな状況でコード書けと言われても無理です。書いてるコードも好きじゃなかった。僕には合わない仕事だったのか能力が低すぎたのか...
お金も稼げそうになかったので、生活に不安が出てきました。
ある日、知り合いの人から、親切な社長さんを紹介してもらって、転職してお金のために働く傭兵に私はなりました。社長さんは技術が学べる良い仕事を紹介してくれました。ご飯も奢ってくれました。
ブラック企業にいた時は、スキルが伸びなかったけど、大手の会社の案件に入れてくれて、大人数でのアジャイル開発やスプリントを学べた。
お給料もちゃんと払ってくれるし高額な報酬を払ってっくれる。他の技術ができるともっと報酬が上がるし、キャリアアップになると提案もしてくれた。
💰SESに入って気づいたこと
設計書はあるし、クリーンアーキテクチャやMVVMを学べた。普段から趣味でriverpod generator
を触ってたのですが、最初に入った案件で使うことがあった。
勉強しておいてよかったよかった。
勉強してたおかげでソースコードは読めた。入った案件では、優秀なエンジニアやたまたま副業で案件に入っていた友達と仕事ができたのは嬉しかった。
新しいRiverpodの書き方を使わない案件もやったのですが、そこでは私、FutureProviderで普段はAPIとやり取りをしていたのですが、StateNotifierのAsyncValueを使う方法を教わりました。
「これ、AsyncNotifierを使った方がいいらしいことを聞いたので後で、個人学習で試したりしてましたね。」
こんな感じですね。APIのデータをfetchするメソッドで、APIのデータをView側にref.watch
して、when
で表示する。新しい書き方だと、switch文で表示する方法が推奨されることを聞くようになりました???
import 'package:microcms_api/core/logger.dart';
import 'package:microcms_api/model/blog_state.dart';
import 'package:microcms_api/repository/microcms_api.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';
part 'microcms_notifier.g.dart';
// ViewとModelの橋渡しをするViewModel
class MicroCmsNotifier extends _$MicroCmsNotifier {
FutureOr<List<ResponseModel>> build() {
return getCategories();
}
Future<List<ResponseModel>> getCategories() async {
try {
logger.d('AsyncNotifierを実行👻');
return ref.read(microCmsApiProvider).getCategories();
} catch (e) {
logger.d('すべてのエラー: $e');
throw Exception(e);
}
}
}
他にはそうですね〜Enum
を使うのがやたらと多かった💦
普段使わないから、radioボタンで使えるのかとか、print
を使うのは禁止!、logger
でlogを出す!
職場のコーディング規則を学んだ。
Flutterの仕事がないと聞く?
そんなことはないけど、自社開発してない企業や他の技術が使えないエンジニアやSESの会社は仕事ないのかもしれないです。
FlutterとFirebaseばかり使ってきましたけど、副業じゃないと使う機会があまりないないですね。大きい会社だと、AWSに設置してるREST APIとhttp
やdio
で通信するアプリを作ってます。
エンジニアってそもそも1個の技術しか使えないと仕事はなかったりします。最近経験したことは、TypeScrptでUnitTestを書いたり、SQLを使ってデータベースのテーブルを確認する作業をやりました。
一番厄介だったのは、OpenAPI
を使ったPJに入った時でしたね。これは自動生成されたソースコードを使うので、どうなってるんだと悩まされました😱
他にやったのは、自分のPCにDockerインストールして、Nest.js起動して、prisma pushしたり、prisma studio使ったり、DBeaverでデータベースのテーブルをGUIで確認する作業をしたことですね。
ある日、コンテナが動かなくなったりして焦ったり、DBが繋がってない?、VScodeのDockerの拡張機能で、アタッチシェルして、Dockerの内部に入って、MySQL
が起動できるか確認もしました。
こんなことがあって、FlutterとFirebase頑張っても意味ないと思いました🫠
現場で求められる技術
面談のときに聞かれますけど、案件の内容に書いてある通りの技術を使います。内容はPJによって違いますね。設計の本も読んでおいた方が良いですね。面談で採用してもらうには、聞かれたことに一つでも多く答えることが必要です。
自己紹介なんて入りません。名前を言うだけ良いです。意外でしょ〜
いらない情報を相手に伝えたり、不都合になることは言わないようにする。聞かれたことに答えるのと、気になったことは質問するとこれだけで、印象は良くなる。
例を出すと:
コードは疎結合で書いてるとか、MVVMだとか...、Swagger使えます?、エンティティはただの入れ物です。
専門用語を連発してくるのでね。元々IT企業じゃない企業はこんなことも知らないですので、そこにいても成長などしないと思いましたね。
もしFlutterで仕事したいなら、この技術をやった方がいいと思った。
- AWS(これはできて当然と思われている。コード書くだけのWebエンジニアでも触る)
- Swaggger (yamlでAPIの仕様書を作ってくれるツール)
- TypeScript (LambdaやNest.jsで使う。型定義をJavaScriptでするのはもう普通みたい。)
- SQL (枯れた技術ですけど、多く使われている。テーブルや外部キーの知識ぐらいは知ってましょう)
- ORM (TypeORMやPrismaを使う。生のSQLはTSのコードの中に書くことはない)
- Docker (これはマストです。ローカル環境でAPIの起動に使う)
- DevTools (NetWorkのエラーで401とか403のエラーが出てないかチェックする)
- Jira (バックログのこともある。タスク管理ツールでチケットと作業内容を確認する)
- Confluence (ドキュメントはここにまとめる。Notionを使う企業もある)
- miro (PJのアイディアや設計図が配置してある。たまに重くて見れないことある💦)
- Figma (AdobeXDのところもある。アプリのデザインや画面遷移図が配置してある)
FlutterとFirebaseはやらなくて良い?
そうでもないですね。Firebaseにも良いところはあります。小さな会社は、APIもサーバーも用意する金もなければ、技術者もいない。
ですので、Firebaseは使いますね。認証、データベース、画像の保存、アプリのクラッシュのログをとる、などなどあります。
私は、副業や個人開発では使いまくってますので、メリットがあるなら積極的に使った方が良いです。
感想
最近は、Flutterを続けているけど、良い評判を聞かない、魔法の道具と勘違いして、導入して失敗している企業があるからなのか、SwiftUIやJetpack Composeで開発する企業が出てきました。まさか、Flutterやめて、Nativeで作り直す例があるとは...
ReactNativeやめて、SwiftとKotlinにリプレイスすることもあるとか?
Flutter Webの仕事だと、あるページではホットリロードが使えなくて、毎回ビルドするなんてこともあって、辛い💦
クロスプラットフォームのデメリットを感じましたが、僕はFlutter好きで捨てる気はないですけど、Nativeでアプリ開発をして欲しいとかそんな案件に入って欲しいという要望があって、SwiftUIとJetpack Composeを学んで、簡単なアプリですが、勉強した知識を生かす成果物としてアプリを2個作りました。
これがSwiftUIで作ったアプリですね。2年ぶりにSwiftのコード書いたら、まさかコード書いて、UI作れるとは...
Jetapck Composeのアプリは似たようなものです。2個目はすごいの作りたいなと思ってます。
仕事では、バックエンドを任されることもあって、Nest.js、Prisma、TypeORMをキャッチアップして、TypeScriptの技術レベルを上げることもできました。自分でPostgreSQLを組み合わせて、CRUDできるアプリケーションを作りましたね。
本を作ったりもしましたね。現場の人は、かっちり型定義をするのを見て驚きました。テストコードまで書いてるからカッコいいな〜と思いました。
独学しても一人で勉強してるだけと自社開発の採用の人に言われたことがあります。
人に認めてもらうにはどうすればいいのか悩みました。それは単純で成果物を作ることですね。後は職歴かな〜
最近私、昔相手にしてくれなかった企業や見知らぬ企業からスカウトが来るようになりました😅
何が言いたいかというと、人に認めてもらうには、成果を出さないといけません。もしできなかったら...
大袈裟ですけど、死ねって思われます。だって、首切られたりしたら生活できませんから😱
頑張ってくださいと言われることありますが、追い詰められてると感じます。これ以上何を頑張ればいいんだ???
東日本大震災が起きたときに、被災者は新聞で、「私たちはこれ以上何を頑張ればいいんですか?」と言ってました。
頑張るとか、頑張ってくださいって言葉は、相手にプレッシャー与えたり、口先だけの人がいたりするので、安易に使わない方が良いな〜と思います。
僕が最近やってること
人から良い評価をされてると僕は思ってません。だって証拠がないから...
人と比べてはいけないというけど、学校や職場や趣味の場でも比較はされてるので、気にはします。これは自分はやめても世の中の人は気にしてる👁️
なので、能力を伸ばして生活を豊かにするのを目標にして、それが実現できれば信頼されてるな〜と思い最近はこんなことをしてます。
- SwiftとKotlinでアプリを作ってリリースする.
- ビジネスロジックを考える.
- コードの内部まで見にいく.
- 大学生相手にプログラミングを教えた.
- 設計パターンを勉強する.
- APIを作る.
SwiftとKotlinのキャッチアップのために、x-codeのPalygroundやIntlliJ IDEAで何度もコードは書いたし、文章かくの下手だけど本も作ってみた。まさかハートがつくとは意外だ💚
まとめ
2023年は大変な年でした。2024年は楽な年にしたいです。僕が望んでいるのは、散歩して買い物に行って、寝る。友達と遊ぶ。普通の日常を送ることです。できれば彼女も欲しいですね〜💙
そのためにも頑張ってることを評価してくれるひとが、いたりしますけど、それは口で言ってるだけだから、企業の人や世の中の人から認めてもらってる証拠がないと僕は安心できません。
だから作ることにした。成果物を作りアピールして、要求されたことを実現するコードを書けるようになる。そうすればエンドさんや社長を喜ぼせることができる。
僕が最近お世話になったエンジニアさんは、1年半しか実務経験がないですが、僕がやろうとしていることを実現していました。
また一緒にお仕事したいと思うFlutterのライフサイクルやriverpodに詳しくて、困っていた時は、いつも助けてくれた良い人でした。
今年は良い年であってほしい😇
Discussion
1年お疲れ様です。
DevTools の活用方法とかは需要ありそう。特に、ちょっと触ったことあるけど実務で活かせてない人は具体的なユースケースを知りたいかも。
その辺の記事を書きたいですね。JWT認証するサンプルあるから、それで実験してみるのがいいかな〜
今度試してみますね。いい感じでできるかわからないですが💦
mockとの通信なら動画出してます。
既出でしたね、失礼しました笑
GitubSearchをやってみると422 error
DevToolsのNetWorkの使い方メモ
422 Unprocessable EntityThe HyperText Transfer Protocol (HTTP) の 422 Unprocessable Entity 応答状態コードは、サーバーが要求本文のコンテンツ型を理解でき、要求本文の構文が正しいものの、中に含まれている指示が処理できなかったことを表します。