段階を踏む
先週、Rustの勉強をするのにとりあえず時間を確保してないと思ってまずは確保だけでもしてみようと思ったんですが、良い結果につながりました。
確保した時間にちゃんとRustに取り組むということはすんなりできたので今週はRustの勉強を進めることができたと思います。
段階を踏む
今思うと何かするのにまずは以下をクリアする必要があったのかなと思います。
- 時間を確保
- その時間に他のことをやってしまわない
自分の場合は2は問題なかったので1をクリアしたらすんなりことが運んだ感じです。
この辺を意識せずに「とにかくやらなきゃ」というやり方だといつまでも何も進まなかったかもしれないと思います。
次は
やったことをどうやってちゃんと身につけるかですかね。
どんなプラクティスいいんでしょうか。とりあえずは必ず最後に振り返る、あたりからですかね…
ところでRustの所有権
この概念はメモリの使い方（管理？）を効率的にするためのものなんですね。
今までJavaをはじめとしたGCに任せっぱなしの言語ばかり触っていたので勉強になるかもしれません。
結局普段使いせずにあまり生かせない可能性もありますが…
1月がもう終わる
早いですね。
今年はRustを勉強しようと思ってましたけどあまり進んでません。
単にもう少し頑張ろう、というのはやめて少し考えてみたいと思います。
そもそも
- どれくらい進むか考えてなかった。そのため今本当に進んでないのかが実は分からない。
- 余り時間が取れてない。時間をかけてないのでそもそも進むわけない、ですね。多分2時間ちょっとしかやってないのでは…？
の2つの問題があります。
まずは2の方を解決したいと思います。
まずは時間を確保しよう
Rustをやろうと考えていた時間帯があるのですが、最近はその時間はあまり確保できていなかったです。
なので別の時間に、量は少なくても安定して確保できそうな時間にRustをやる、ということができるようになりたいと思います。
平日の30分くらいはできるかな、2.5×4で1ヶ月で10時間くらいですね…こうしてみると少ない…
でもまずはこの時間をちゃんと確保することを頑張りたいと思います。
この時間は頑張ってあとはダラダラできる、と考えればできるはず…
リファクタリングの成果？
リファクタリングをしてその後にその効果を実感することって今までなかったんですけど、来週はそのチャンスがあるかもしれません。
リファクタリングの内容は複数責務を持っていたクラスからその一部を別クラスに抽出した、というものでした。
で、今回はその抽出部分だけに関連した機能トグルを実装する、という修正をするかもしれません。
今まではコードをキレイにするというのを心がけてはいてもそれによって修正が楽になったとかは無かったのでちょっと嬉しいですね（今までが下手だっただけという可能性…）
折角なので
リファクタリングしてなかったらその修正がどれくらいやりづらかったか、というのも見てみたいです。ちょうど余裕がありそうですし。
実際やってみたら対して差を感じなかったりして…
やらないことはやらない
RustのHello Worldをやっていてビルド出来なかったんですが、その時ビルド出来ない原因とかちゃんと理解してQiita投稿でもしようかな？って？思ったんですがやめました。
理由としては最初に決めたRustで覚えたいことに影響しなそうだったからです。ある意味余計なことに時間を使わなくて済んだのでよかったです。
なぜ投稿しようと思ったか
これはアウトプットの練習になるかな？というのが主な理由でした。
一見良さそうな行動でしたが、Rustで覚えたいことに影響しなそう→ある意味無駄な行動かなとも思いました。
効果的かどうか考える
なんだか良さそうだからやろう、みたいな発想になりがちなんですが自分の目標への貢献度が低そうなものはやらない、という考えも身につけたいと思っていたので良かったです。
Rustで勉強したいこと
今年はRustを勉強してみようと思うのですが、最初に目標を決めて年末にどうだったか評価できるようにしておきたいと思います。
理解したいこと
所有権
この概念は今まで触った言語にはないと思うのでなぜ出てきたのかは理解できるようになりたいです。
構造体
今までJava的なクラスにデータとメソッドを定義するような言語がメインだったので、なぜクラスはなくて構造体でデータを定義するのか理解したいと思います。
テストに関すること
Rustではどのようにテストを書くのかも理解したいです。特徴とそのメリットを理解して普段使う言語で応用できる部分があるといいですね。
やらないこと
あまり深追いしないことも決めておきたいのですが…難しいですね。
とりあえずは勉強する中で目標にあまり関係ないけどつい深追いしてしまうことなどを自覚出来るようにしたい、というところでしょうか…
今年やったこと
このブログをはじめた
アウトプットの練習としてはじめましたが予想より難しいなと思いました。5行くらいの記事かな、と思って書き始めてもなんかダラダラ長くなってしまいますね、
まとめる練習として続けたいなと思います。
ちなみにqiitaも一件だけ書いたんですが、2,000回くらい表示されてたみたいでこちらも2,3ヶ月毎くらいには書いてみようかな、と思いました。
（2,000って数字だけ見ると初心者としてはオッなりますよね）
ソシャゲ
こちらはダラダラ時間を使ってしまった、というやつですね。
やらないことを決めるのが大事なのかな、と思いました。来年は辞めるとは言いませんがとりあえず時間かけて周回、みたいなことはやめたいです…
Haskell
こちらは全然できた感じがしないです。目標が曖昧すぎたというのもあるのかなと思います。
来年はRustをやってみたいので最初にある程度目標を決めてやりたいです。達成できるか、というよりはその目標に対してどうだったか、という評価を年末に出来ていたいです。
今年は何も評価出来ない状態なので…
一つのことをうまくやる
最近 clean architecture と clean coder を読み返したんですが一つことを上手くやるって忘れがちだなあと思いました。
コード書いてるとつい既存のものにちょっと別のものを入れてしまうっていうのはありがちですね。で、それがちょっとずつ肥大化して…
抽象度を変えてみる
一つのことをやる上で抽象度をセットで考える、ということが書いてあったのですがそれは全然やってなかったですね。
例えばサービス層のメソッドだとデータ取り出してそれのドメインロジックを呼び出して、、、みたいなことをやるので一つのことだけやるなんて無理じゃん…
とはならないわけでこの場合は必要な一連の処理を呼び出す、という一つのことをやってると考えるということですね
こういう考えはあんまりしてなかったのでプログラミング以外でもこういうふうに考えてみたいです。例えば（抽象度とは違うかもしれませんが）このタスクは年度レベルではどんな意味を持つか、四半期レベルでは、プロジェクトレベルでは、週単位では…
もしかしたらこれによって今やらなくていいこととかが見えてくるかもしれないと思いました。
