コードを書くときは、cursorを使っていこう。
intelijは便利なgit、sqlクライアントとして使っていこう。
v0によってフロントエンドの仕事の範囲が変わってくるかもしれないけど、できれば、フロントをやっていきたい。
年末年始でrails学習してみたが、すぐに仕事に生かせないので、一旦休もう。 引き続き不明点は学習しようとは思うけども。
学習領域深さを追うか、ずらして、違う領域やるか。 両方なんだと思う。ずっと同じことは飽きてしまいそうなので、ほどほどにスイッチしながらやっていきたい。
それと、ドーミーインで温泉・サウナに入りたい。 熱海温泉旅館に泊まりに行ってにノートとペンだけ持っていて今後について考えたい。
仕事に全力でした。 今は大丈夫ですが、仕事終わってご飯食べて疲れて寝落ちしてしまうような時期もありました。 気疲れ？
後半は、カンファレンスに行けました。
kaigionrails.org rubyやrailsが好きなひとがきているなという印象で、僕もやっていくぞという気持ちになりました。
kansai.tskaigi.org 仕事で書いていますが、新しい発見が多かったです。
転職して2年目に突入しました。
フロントエンドを全力でやってきましたが、来年は、バックエンドも見ていこうと思います。
たまたま本屋でみつけて、読んでみた。 DHHさん共著ということで目がいった。
現在、ありがたいことにフルリモートワークできていて、満足しているが、よりできていることに感謝できた。 満員電車もう乗りたくない。
本書の内容は、リモートワーク最高だなと思うような内容と、より集中していく方法。 人材の採用などリモートワークんまつわる内容がたくさん書かれている。
集中する方法で、自分で思考したのが、slackや常にボイスチャットでつながっていることでのメリットもあるが、深い集中に関しては、できていないと感じた。
意識的につながらないで、集中していくというのも必要だなと感じる。 常に、話すかもしれないと思いながら、目の前のコードに集中するのはできるが、僕には、消耗も激しい気がする。
集中しながら長くやるには、1日の何時間かはひとりで深く集中する時間を作っていきたい。
AppRouterを調査していたが、仕事で使う予定がないのと、興味だけで学習してもモチベが保てないと思い、やめた。また、時間があれば触ってみたい。
仕事の現場のバックエンドがRailsなので、久しぶりにRailsを触ろうとしたら、dockerでうまくできなくて、つらかったので、homebrewも過去やっていて環境がどこまでやったかを確認しながらやるのものつらいので、UTMというアプリで仮想環境を作って、そこに一からrubyとRailsを入れるという方法にしてやってみた。
Ubuntu Desktopを触るのはとても久しぶりで、5年前windowsで学習していた時以来となるのだが、aptは優しいなと感じた。
失敗してもまた、仮想環境を作るだけやでと思ってやってみた。
ubuntuの日本語環境のisoがなくなっていて、英語版をやってみた。 前はインストールが簡単だったが、これは、手順があるようだった。
graphiql-railsをいれたところで、力尽きたので、また、来週触ろうと思う。
ものぐさなので、macからubuntuにsshで入って、vimでファイル編集している。 画面の確認は、ubuntuのdesktopのfirefoxからしている。
理想は、鍵を作って、vscodeでubuntu内のファイルを操作し、mac側のブラウザで画面を確認するんだと思うのだが、設定がめんどくさくてやっていない。
vimrcはいじるかもしれないが、今のところ、これぐらいの設定でgraphqlを学習したいと思う。 仕事では、フロントしか書かないが、少し、バックエンドもキャッチアップしておきたい。
vimだけでやろうと思うが、vscodeやinteliJみたいに便利に僕は使えない。
不便を楽しんでいる。 vimだけだとなんかかわいい。
参考にさせてもらったサイト
https://oopsoop.com/ubuntu-on-mac-using-utm4/
https://phoenixnap.com/kb/install-ruby-ubuntu
昔よりも、開発環境にこだわりがなくなった気がする。 少し前ならdockerでやるんだと、挫折しながら、時間切れで環境が作れず、週末を消化していたはずだ。
今日は、graphqlをrailsで実装する環境ができれば、良くて、それが目的だからそのほかどうでもいいので、それ以外はこだわらないという判断ができた。
現状考えていることをまとめる。
01でこれが、できたら100%これができなかったら0%ではなくて、これは、60%できた、80％できたというような感じで自分ができたことを評価していく。
0から100段階があり、どのくらいできたかで成果を評価する。
当たり前からもしれないが、できなかったら0でできたら100の評価をするとできなかったときの精神的ダメージがでかい。 これができなかったら、だめではなくて、できたところまでを評価して自分に優しくすることが必要。
100できなかったら、だめ0点ではなくて、できたとこで評価する。
そもそも、できなくても自分の価値が下がるわけではない。
その与えられた環境で、実力がないということであれば、まわりが変化する方向、例えば、アサイン変わるとかになるはずだから、自分で自分を傷つける必要はないと思う。
0、100思考だと完璧でないとだめというふうになってしまうが、そんなことはない。
Youtubeや自分で咀嚼して考えたことをまとめた。
写経しながら試す。 一部変えたりして、動きを試す。
useStateでは、複雑になりそうなケースについて、useReducerを使うといいっぽい。
import {useReducer} from "react"; function reducer(state, action) { switch (action.type) { case 'increment_age': return { age: state.age + 1 } case 'decrement_age': return { age: state.age - 1 } default: throw Error('Unknown type'); } } export default function App() { const [state, dispatch] = useReducer(reducer, {age: 40}); return ( <> <button onClick={() => { dispatch({type: 'increment_age'}) }}> increment age </button> <button onClick={() => { dispatch({type: 'decrement_age'}) }}> decrement age </button> <p>age is {state.age}</p> </> ) }
参考 ja.react.dev
アクティブリコールやリトリーバル観点で、考えるとプログラミングのいわゆる写経について思ったことを書く。
サンプルコードを見ながら、一文字ずつ、写していくのはだめで、見本を見て、何も見ずに、自分の頭で思い出しながらある程度の塊で、書いて、見本を確認して違ってたら直してみたいなことをやっていくと良さそう。
もしくは、プログラム全体を見て、流れを把握して、何も見ずに、おおまかにこう書いてあるなというのを思い出して、アウトラインだけ書いて、もう一回見本見て、詳細を見ずに埋める。
とかがいいのではないかと思った。
具体的なステップ
学校のテストではないので、100%できる必要はなくて、コード補完がでるぐらいまでの頭出しとしての記憶ぐらいでよいと思われる。
それよりも知識の広さが重要だと思われる。
公式を目次として、ブログで理解しやすいものを探して、学習してまた、公式の目次に戻って内容を把握するのが良さそう。
