Yumemiのコードチェックをやってみた
Yumemi社のコーディングチェックをやってみようと思ってやり始めたら、思いの外興が乗ってしまった。
コーディングチェック最初は真面目に取り組もうとしていたのだけど、途中から方針ががらりと変わって自分の学習用の場になってしまった。
始めてから大体1週間位経ったので現在の経過を書いておこうと思う。
Yumemi社のコーディングチェックをやってみようと思ってやり始めたら、思いの外興が乗ってしまった。
コーディングチェック最初は真面目に取り組もうとしていたのだけど、途中から方針ががらりと変わって自分の学習用の場になってしまった。
始めてから大体1週間位経ったので現在の経過を書いておこうと思う。
Droidkaigiのリポジトリのように、マルチプロジェクトで設定ファイルを共有する仕組みを知りたいと思って幾星霜。
今まで重い腰が上がらなかったのだが、Wear OSのプロジェクトが設定をベタ書きにしており非常につらい思いをしていたので、必要に迫られてやることにした。誰かの参考になれば幸いである。
解説を見てもまるでわからんとなったので、しばらく考えてようやく理解できたのでメモ。
それまで習得した技の合せ技となっており、復習という意味でも良問だったように思う。
結果的には前回と変わらずABの2問しか解けなかった。
タイピングミスで集中力が乱れたり、問題文の理解に苦労したりということはなかったものの、Cは時間内に解くことができなかった。パフォーマンス的にはいつもと変わらない感じではあった。Cが解けなくてDを考えようか、いややっぱCをやったほうがいいなと問題行ったり来たりしたのもよくなかったかもしれない。
コンテストの結果はさんざんだった。あとからやってみたら素直に解けて、これが本番で出来ていればと思わずにはいられなかった。本番の状態ではとてもじゃないけど、できなかったけどね。
ForkというGitのGUIツールを購入した。
購入の決め手となったのは、インタラクティブリベースがものすごくやりやすいことだった。rebase作業がめちゃめちゃ捗る。
最近になってようやくJetpack Composeを触り始めた。
はじめはとっつきにくいなあ、レイアウトはXMLでいいじゃんとか思っていたのだが、慣れてしまえば不思議なものである。レイアウト見るためにいちいちXMLファイル見に行くほうが面倒くさいじゃんと今では感じるようになった。
しかしJetpack Composeでもよくわからないことがある。それがModifierである。
Gradleの機能として提供されているversionCatalogsを使って依存関係を定義してみた。
Gradleでライブラリの管理を便利にできそうなプラグインを見かけた。refreshVersionsというプラグインだ。
buildSrcを使って一括管理する方法は知っていたが、プロジェクトごとに用意するのも面倒くさい。なにか楽な方法はないかと思っていたが、これはその解の1つとなりそう。
Fragmentでの初期化処理を行う場所どこだっけとなったので備忘録として残しておく。
処理する場所が変わったんだな、ということだけは記憶にあったのだが、結局どこになったのだったかなと迷ってしまった。この先何回も遭遇しそうだったので、ブログに残しておこうと思う。