2022年の振り返りと2023年の意気込み
気づけばもう2022年が終わる…。ブログも1年ぶりの更新に…。 去年の振り返りのブログで意気込みを書いてましたがまったく覚えてませんでした。
2022年の意気込みは以下の3つだったみたいですので、まずはこの項目に沿って振り返ります。
- 技術のインプットを増やす
- 「こういうことができます」という成果を残す
- Rustを学ぶ(おまけ)
技術のインプット
本業でチームが変わったこともあり、色々と技術のインプットはできたかなと思います。あとは副業でも大きなリニューアルがあり、色々と新しい経験を詰めたのは良かったです。ぱっと思い浮かぶ新しい知識はこの辺です。
あとは自分のできることとできないことを棚卸ししたり、「次はこれやりたいな〜」っていうのを選んだりもしました。 知らないことたくさんあるなあ〜って思うのと同時に、知らないことの中からどこから手を動かして学んでいくのか優先順位をつけやすくなった気はしてます。たまに振り返って更新しています。
総じて2022年は技術的なインプットを増やせたのでちょっと満足しています。まだまだなので2023年も頑張っていきます。
「こういうことができます」という成果
一言でバシッと言うのは難しいのですが、「こういうことやりたいよね」と話し合ってチケット切ったけど放置されて埋もれてしまった改善タスクに優先順位をつけてそれをチームで実施・改善していくプロセスをチームに装着できました。成果で言うとライブラリのバージョンを上げるとか、デプロイパイプラインを整備するとか、チームの当たり前を底上げしていくみたいなことができたのではないかなと思います。 別に大変なことを成し遂げたわけじゃなくて、「やったほうがいいことは少しずつでもやっていきましょうよ」っていうのを推進していました。
Rust
こちらの本の重要な部分を読んで「ほーRustってそういうことを達成するためにこういうのがあるのか〜」みたいなのを知って、基礎の基礎を学びました。
あとはRustで作るRDBMSを実際に手を動かして写経したりして作ったり、副業で使いたい便利ツール(開発に便利なデータをfirestoreに突っ込むツール)を作ったりしました。
一旦満足しています。
2023年の意気込み
技術的なインプットの継続
やっぱりエンジニアなのでHOWにもこだわってインプットを続けたいと思います。特に最近は本を読むことをサボりがちなので、本を読みたいと思います。まずはDesigh It!を読破します。
運動して痩せる
痩せます！
2021年の振り返りと2022年の意気込み
2021年をざっくり振り返って、2022年の意気込みを書いていく。
2021年の振り返り
仕事はぼちぼちやってて苦しんでいる
本業ではWEBフロントエンドをメインでやることになりました。正直圧倒的成長を感じたりはできておらず、自分が環境を活かせてないなぁみたいな気持ちです。
色々書きたいんですが、どこまで書いて良いかもわかって無くて怖いのであんまり書けません…！！！
副業もやっていて、技術的な新しいインプットは今の所副業で補っている感じです。 Nextjsとfirebaseを使っていて、日々firestoreに悪戦苦闘しています…
本を自分にしてはたくさん読んだ
本を読むのが遅い+読んでたら眠くなってしまうのでどうしても1冊読むのに1ヶ月くらい費やしてしまうんですが、2021年の4月頃から色々読み始めて7冊くらい読めました。(あれ、10冊くらい読んだと思ってたけど全然読んでなかった…)
エンジニアなら技術書を月に1冊読もうというのを新卒研修で聞いたので頑張ろうと思ったんですが、仕事始めたら自分はどの技術を身に着けたら良いかも分からないし、ソフトスキルの低さを感じることが多かったので、やや技術からは遠いところも読んでました。
2021年読んだ本
- レガシーコード改善ガイド
- アジャイルサムライ
- カイゼン・ジャーニー
- 問題解決プロフェッショナル
- リフレクション 自分とチームの成長を加速させる内省の技術
- ドメイン駆動設計入門
- Webフロントエンド ハイパフォーマンス チューニング
どれも良い本でしたが、リフレクション 自分とチームの成長を加速させる内省の技術とかが個人的には一番良かったなぁと思っていて、仕事で「もやっ」とする瞬間や楽しく働けている瞬間を思い浮かべて「あれ、俺が何が嫌なんだろう〜」とか「何をやりたいと思ってるんだろうなぁ」という内省を少しずつ意識するようになりました。 あとはチームメンバーに「何を大切したいと思っているのでしょう？？」みたいなことを聞いてお互いの価値観の違いを認識できたりした経験も良かったなぁと思いました。
貯金と投資頑張った
お金周りを意識するようになりました。家賃と管理費で5.7万円のお家に住んでいるので他の一人暮らししている同期よりはゆとりある生活を送っている気がします。
積立NISAはもちろん、ふるさと納税とドル建て保険に入ったりしました。あとはマイニングはじめました。
他にもおすすめ投資がありましたらこっそり教えて下さい。
2022年は…！！
技術的なインプットをもう少し増やすぞ
「あぁ〜やっぱりちゃんと技術吸収しておきたい！！」という思いと、「自分はどういうスキルを求めているんだ…？？」という疑問を今年は払拭したいなぁと思います。 今の所、アーキテクチャや設計に関する書籍を読んで…いきたいなと！
根本にはt-wadaさんのこの公演の内容があります。 エンジニアリングで事業の成長を加速させる、競合に負けない・時代の変化に追従する俊敏性を保つ開発をできるようになりたいぞ〜と思ったのが大きいです。「それにはアーキテクチャの知識って大切そうだけど、自分何も知らないなぁ」となってます。
あとはやっぱり手を動かしてWEBフロントエンド周辺の技術も触っていきたいと思います〜〜2021年の後半はapex始めてしまったのが良くなかったです！！！！！ 今年こそはRustを触りたいです。1年に1つの言語を…と聞いたので！
「こういうことやりました」「こういうことできます」という成果を残す
頑張りたい！
Sidekiqのジョブを走らせたくないけどキューイングだけ確認したいときは Sidekiq::Testing.fake を使うと良さそう
Sidekiqを使っていて，slack通知をsidekiqのジョブとして行うようにしました．
しかしそのジョブを実行するAPIのテストを回すと，テストなのにジョブがキューイングされてslack通知が来てしまいました．
ただテストを回したいのにアプリケーションと同じようにジョブが振る舞っていたので，テストのときだけジョブを無効にするか，env=testで動作させるいい方法を探していたら，Sidekiq::Testing.fake! を使うと良さそうだとわかりました．
こんな感じでリクエスト送ってるところを囲ってあげるとジョブの中身は実行されません．ジョブの中身のテストだけ別途書いてあげれば良さそうです．
Sidekiq::Testing.fake! do
post "/api/v1/xxx", params: { ... } # slack通知を伴うAPI
end
ここではジョブのキューイングだけを確認するだけで良さそうです．
キューイングされたジョブの個数を取得する場合はこんな感じです！
XXXXWorker.jobs.size
よくできてますよね．．．感動しました．
必死に
envがdevのdockerコンテナを落とす => envをtestに設定して立ち上げ直す => テストが終わったらまたenvがdevのものを立ち上げる
とかそういうのを試行錯誤していました...
参考
seed_fu使ってシードデータを作ったのにrspecのテストを回すとシードデータが消えている
rspec使ったテストを書き始めたので，github actionsでのCI環境でもテストを回るようにしたところ...
rspecを実行するとシードデータが消えていることがわかりました．
原因
spec/rails_helper.rb にある以下の記述が原因みたいです．
これはテストが始まる時にmigrationがちゃんとできてるかどうか確認してデータベースのスキーマをschema.rbに合わせるみたいです． もしmigrationを行う場合，DBを綺麗に消しちゃうみたいで，それによってseed作っても消えちゃってた様です．
begin ActiveRecord::Migration.maintain_test_schema! rescue ActiveRecord::PendingMigrationError => e puts e.to_s.strip exit 1 end
解決策1: seedをrspec実行時に作るようにする
spec/spec_helper.rb に以下を追記するとよいです．
config.before(:suite) はrspecを実行する前に1回だけ行う処理をかけるみたいです．
RSpec.configure do |config|
...
config.before(:suite) do
SeedFu.seed
end
...
end
解決策2: Seedを作っても消えないようにする
ActiveRecord::Migration.maintain_test_schema! を無効にします．
config/environment/test.rb に以下の1行を追加します．
config.active_record.maintain_test_schema = false
この場合，migrationをRAILS_ENV=test と指定して回す必要もあります．
CIなどの一連の流れはこのような感じに（github actionsなどではもっと楽にenv を指定するだけでOKです）
RAILS_ENV=test rails db:setup RAILS_ENV=test rails db:seed_fu RAILS_ENV=test bundle exec rspec
参考
自作キーボードで配列を変えても2ヶ月あればプロダクションレディになれる
4月から社会人になりましたが、ちょこちょこ「キーボード買わなきゃ」とか「自作キーボード気になる」 というワードを見ます。
新入社員の皆さんはきっと研修が続くと思います。
なので自作キーボードを作って、配列を変えても、2ヶ月後にはプロダクションレディな習熟度になっていると思いますので、作るなら今だぞという気持ちで書きます。
ちなみに、全然ガチ勢じゃなく、にわかです。
以下のことについて書きます。
- 自作キーボードを選んで買うなら
- 配列変えた後のタイピング数の動き（N=1）
自作キーボードを選んで買うなら
他にも色んなサイトがありそうですが、以下の2つが候補になると思います。
遊舎工房
オンラインでの販売もありますし、秋葉原にも店舗があります。
最近はここで買う人が多いのでは？？
必要な部品はすべて同梱されているので分かりやすくてミスもないのが良いところだと思います。
店舗には工作できるスペースもありますし、キーキャップもたくさん置いてます！
Keebio
僕は遊舎工房ができるちょっと前に作ったのでKeebioで買いました。
遊舎工房より種類が多い印象です。
また、アクリル以外の部品のみ買い、アクリル(外装)だけは自分で好きな色・柄を買うことで見た目もオリジナルにできます。
僕は渋谷のFabCafeでアクリルを切りました。色がついたアクリルを使うなどして楽しみが増えます。
アクリルをレーザーカッターで切る際にもネットにIllustratorのファイルが落ちてるので専門的な知識は不要でFabCafeいって「これでおなしゃす」と頼めばOKだったはず。
FabCafe Tokyo - 3Dプリンタとレーザーカッターが使える渋谷 道玄坂のカフェ
木を加工して作ることも可能です。
配列変えた後のタイピング数の動き
これは自作キーボードを使い始めてからの寿司打のスコアです。
がくーーんと落ちてるところは、配列をQWRTYからWORKMAN配列に変えたためです。
そこから2ヶ月でプロダクションレディな3[タイプ/秒]にたどり着いています。
毎日コツコツやれば少しずつ早くなるので勇気をもって、配列も変えちゃってくださいね！！！
Macで「30日でできる！OS自作入門」の進め方と簡単な書評
いい本でした
最終的な成果物はこちら
環境構築
基本的にはこちらのQiitaの記事を参考にして環境構築を行います．
進め方
リポジトリは完成形が置かれていてmake run するといい感じに動くようにやってくれています．
僕は自分でコードを書きながら進めたかったので，リポジトリのコードを写経しながら進めました． 具体的には以下のような形で進めました．
- リポジトリのメインとなるファイル(
helloos.nasやipl.nas)をリネーム - メインとなるファイルを作成 or 1つ前の章で作成したものをコピペ
- リネームしたものにコードを書く(本家のリポジトリor参考のリポジトリを写経)
リポジトリのものを写経するのは，本にはソースコードの全体像が載ってないからです． 本にも書かれてますが「プログラムがメインで，その添付資料が本」みたいな感じです(作者じゃない読者がこれを言うと色々批判がありそうですが，悪い意味ではありません)
macでやると，本と同じようにできないので結構つまづきます．躓いたらzacfukudaさんのリポジトリを参考にしてました．
どこで躓いて，どう対応したかを丁寧に書いてくださっていますので，macユーザーにはとても助けになると思います．
得られた知識
OSがどうやって画面を描画しているか，OSの基礎的な知識と学校の授業でも習わないような詳細な知識とテクニックを学べました．
例えば．．．
- メモリ領域を守るために，CPUの機能を使ってメモリへの不正なアクセスを防ぐ
- キーボードやマウスの入力があった場合の割り込み処理の実装
- 割り込み処理をできるだけ短時間にするための工夫
- OSのAPIを作成し，APIを利用したアプリケーションの開発
などなど．
OSってどうやって動いてんの〜みたいなところが学べたので，PCとかスマートフォンのOSってすげぇな！って思うようになりました笑
その他
高速化したつもりがカクカクなる
これは今のPCが高機能すぎるがゆえ起こることらしい．
エラーの対応
結構最初にでてきたこのエラー．．．
error: attempt to reserve non-constant quantity of BSS space
これは以下のブログを参考にして解決しました！
18日目のharib15gでstrcmp関数を自作するときはこちらを参考にしました． stdio.hとかはincludeできないので諸々自作していきます．
http://bttb.s1.valueserver.jp/wordpress/blog/2018/02/12/makeos-18/
20日目にmapファイルを見たい場合は以下のオプションをつけると良さそうです
-Wl,-Map=bootpack.map
Makefileはこんな感じ
OBJS_BOOTPACK = bootpack.o graphic.o dsctbl.o naskfunc.o hankaku.o mysprintf.o int.o fifo.o keyboard.o mouse.o memory.o sheet.o timer.o mtask.o mystrcmp.o file.o window.o console.o
CC = i386-elf-gcc
CFLAGS = -m32 -fno-builtin
bootpack.hrb : $(OBJS_BOOTPACK) hrb.ld
$(CC) $(CFLAGS) -march=i486 -nostdlib -Wl,-Map=bootpack.map -T hrb.ld -g $(OBJS_BOOTPACK) -o $@
27日目にライブラリを作るんですが ld とかar だとうまくいかないので，以下のコマンドでライブラリ化してました．
OBJS_API = api001.o api002.o api003.o api004.o api005.o api006.o \
api007.o api008.o api009.o api010.o api011.o api012.o \
api013.o api014.o api015.o api016.o api017.o api018.o \
api019.o api020.o api021.o api022.o api023.o api024.o api025.o \
api026.o api027.o
apilib.a : $(OBJS_API)
i386-elf-ar rcs $@ $^
生成したダイアログでRiverpodで提供しているStateの変更を反映させる
Riverpodの使っているFlutterのアプリケーションで，StateNotifierで提供しているオブジェクトをwatchし，それをダイアログに渡して表示させたり，stateを変更したい場合，ダイアログそのものでwatchする必要がありそうです(引数で渡すだけではNG)．
Dialog内でもStateNotifierから提供させるオブジェクトをwatchしてあげないと，stateの変更がUIに反映されませんでした．
もちろん，ダイアログも ConsumerWidgetを継承させてあげる必要があります．
class Dialog extends ConsumerWidget {
@override
Widget build(BuildContext context, ScopedReader watch) {
final viewModelState =
watch(XXXNotifierProvider().state);
final viewModel =
watch(XXXNotifierProvider());
return Dialog(．．．);
}
RiverpodのStateNotifierProviderが返すオブジェクトはシングルトンになっているので問題もないです．
Riverpod，便利ですね．．．
