と書くとき、UかTのどちらかが同じクレートにいればいいのか…!
なんでそういうルールなのかまでは理解しきれてないが、一旦これが合法というのは理解したぞ
chatgpt.com/share/6766a2...
と書くとき、UかTのどちらかが同じクレートにいればいいのか…!
なんでそういうルールなのかまでは理解しきれてないが、一旦これが合法というのは理解したぞ
chatgpt.com/share/6766a2...
そんなことできるのか
chatgpt曰く孤立型ルールに抵触するからダメと
よく分からない。。
そんなことできるのか
chatgpt曰く孤立型ルールに抵触するからダメと
よく分からない。。
githubactionsの未使用の依存関係チェックで怒られた
adapterレイヤーのanyhowの依存、確かに足したけど使ってないな
章単位でブランチ切って各章終わったらdevにマージしていくという進め方をしていたけど、そもそもそんなこと想定されていない気がするしこれで詰まるのもしょうもないな…
githubactionsの未使用の依存関係チェックで怒られた
adapterレイヤーのanyhowの依存、確かに足したけど使ってないな
章単位でブランチ切って各章終わったらdevにマージしていくという進め方をしていたけど、そもそもそんなこと想定されていない気がするしこれで詰まるのもしょうもないな…
これはrustcのバージョンを上げずに再現するには毎回書籍のリポジトリからcargo.lockをこぴってこないといけないのか…?
これはrustcのバージョンを上げずに再現するには毎回書籍のリポジトリからcargo.lockをこぴってこないといけないのか…?
4章の写経をしていたらp.88でadapter(リポジトリ)がkernel(サービス)に依存しだして『レイヤードアーキテクチャは上位⇒下位の依存なんじゃないの…?』となったが、サービスまでは上位から下位でリポジトリとの関係はDIPで下から上の依存、みたいなのが一般的、という学びを得た
4章の写経をしていたらp.88でadapter(リポジトリ)がkernel(サービス)に依存しだして『レイヤードアーキテクチャは上位⇒下位の依存なんじゃないの…?』となったが、サービスまでは上位から下位でリポジトリとの関係はDIPで下から上の依存、みたいなのが一般的、という学びを得た
rustのバージョンは揃えてた気がするけどなんでなんだろう
が一旦解決したので今度こそ4章にすすむ
#rustによるWebアプリケーション開発
rustのバージョンは揃えてた気がするけどなんでなんだろう
が一旦解決したので今度こそ4章にすすむ
#rustによるWebアプリケーション開発
それでも解決できなかったら一旦全リセットかな
それでも解決できなかったら一旦全リセットかな
cargo make でめちゃくちゃ設定しておいたことによってgithub actionsのワークフローのyamlの記載もシンプル&何やってるか分かり易くて嬉しいな
とか思いながら3章分のブランチ⇒devへのプルリクエスト発行したら
さっきローカルで起きたのと同じエラーだ…
cargo make でめちゃくちゃ設定しておいたことによってgithub actionsのワークフローのyamlの記載もシンプル&何やってるか分かり易くて嬉しいな
とか思いながら3章分のブランチ⇒devへのプルリクエスト発行したら
さっきローカルで起きたのと同じエラーだ…
rustcのバージョンを最新のnightlyにしてtargetも全消ししてビルドし直したらなぜか治った…なに
調べても特に同じところで詰まってる人はいなかったから環境構築周りでそもそも何かミスってる可能性もあるが一旦解決したのです進む。。
rustcのバージョンを最新のnightlyにしてtargetも全消ししてビルドし直したらなぜか治った…なに
調べても特に同じところで詰まってる人はいなかったから環境構築周りでそもそも何かミスってる可能性もあるが一旦解決したのです進む。。
vscodeでプロシージャルマクロが云々で怒られるから
settings.jsonに以下追加して赤線は消したが、結局ビルドは通らずだ
"rust-analyzer.procMacro.enable": true
idnaってなんだ……
vscodeでプロシージャルマクロが云々で怒られるから
settings.jsonに以下追加して赤線は消したが、結局ビルドは通らずだ
"rust-analyzer.procMacro.enable": true
idnaってなんだ……
let mut database_config = DatabaseConfig {
host: "localhost".into(),
port: 5432,
username: "user".into(),
password: "pass".into(),
database: "app".into(),
};
chatgpt.com/share/67409c...
let mut database_config = DatabaseConfig {
host: "localhost".into(),
port: 5432,
username: "user".into(),
password: "pass".into(),
database: "app".into(),
};
chatgpt.com/share/67409c...
文字列リテラルのままだと所有権は借りてるだけだから
リテラルのスコープが切れたら使えなくなっちゃうと
だから一回into()でString変換して自分で所有権を持たせてあげると
文字列リテラルのままだと所有権は借りてるだけだから
リテラルのスコープが切れたら使えなくなっちゃうと
だから一回into()でString変換して自分で所有権を持たせてあげると
rustを推す時によく使われる「強力なパターンマッチ」というフレーズよく分かってなかったけど、こういうところもか
rustを推す時によく使われる「強力なパターンマッチ」というフレーズよく分かってなかったけど、こういうところもか
当然のように回答があった
親ルーターに一度だけ定義してそれ以外はその子ルーターとする、と。。
chatgpt.com/share/67400b...
当然のように回答があった
親ルーターに一度だけ定義してそれ以外はその子ルーターとする、と。。
chatgpt.com/share/67400b...
Stringがヒープに置かれた文字列の実体で&strがその参照、と。。
戻り値で新しい文字列を生成したときはStringで所有権ごと返して
引数で受け取る時はリテラル文字列もStringの参照も扱える&strが多いと。。
リテラル文字列の実体は& 'static str である、と。。
Stringがヒープに置かれた文字列の実体で&strがその参照、と。。
戻り値で新しい文字列を生成したときはStringで所有権ごと返して
引数で受け取る時はリテラル文字列もStringの参照も扱える&strが多いと。。
リテラル文字列の実体は& 'static str である、と。。
portだけu16フィールドだから?
fn from(cfg: DatabaseConfig) -> Self {
Self::new()
.host(&cfg.host)
.port(cfg.port)
.username(&cfg.username)
.password(&cfg.password)
.database(&cfg.database)
}
portだけu16フィールドだから?
fn from(cfg: DatabaseConfig) -> Self {
Self::new()
.host(&cfg.host)
.port(cfg.port)
.username(&cfg.username)
.password(&cfg.password)
.database(&cfg.database)
}
モデルの変換ロジックは変換先の都合にそもそも依存しやすいから、変換先側に対して実装するのは自然なことなのかも、という理解をした
into()で実際にどう変換されるかは文脈で判断してくれるのもよい
モデルの変換ロジックは変換先の都合にそもそも依存しやすいから、変換先側に対して実装するのは自然なことなのかも、という理解をした
into()で実際にどう変換されるかは文脈で判断してくれるのもよい
知らないことが多すぎてどうしても牛歩になるなぁ
git運用とかブランチ操作にも慣れたいので章単位でブランチ切って日々はそこにコミット+都度都度devにマージという形にしてみる
知らないことが多すぎてどうしても牛歩になるなぁ
git運用とかブランチ操作にも慣れたいので章単位でブランチ切って日々はそこにコミット+都度都度devにマージという形にしてみる
・エラー処理を簡潔に行うために?演算子を使いたい
・?演算子で早期リターンするためには戻り値の型をResult型にしておく必要がある
・ただ実際に戻り値を使いたいわけではない
・成功時の型を空のタプルにすることで何も返さないことを明示
ということなんだ
・エラー処理を簡潔に行うために?演算子を使いたい
・?演算子で早期リターンするためには戻り値の型をResult型にしておく必要がある
・ただ実際に戻り値を使いたいわけではない
・成功時の型を空のタプルにすることで何も返さないことを明示
ということなんだ