From fe7537f238f49252626e1fdf1c35bbae39085fae Mon Sep 17 00:00:00 2001 From: Myrddin Dundragon Date: Tue, 25 Mar 2025 22:22:19 -0400 Subject: [PATCH] Moving personal review and adjusting README. Just making the project a little more tidy. --- README.md | 38 +++++++++++--------------------------- docs/personal_review.md | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 27 deletions(-) create mode 100644 docs/personal_review.md diff --git a/README.md b/README.md index c0e3c28..375e54d 100644 --- a/README.md +++ b/README.md @@ -1,33 +1,17 @@ -# FileMonitor - +# FileMonitor # This was a Rust Challenge that I completed in 17 hours. -## Review ## -I thought I solved the challenge pretty well. I took my time and went back -and refactored and commented well. +The [document](./docs/rust_coding_challenge_filemonitor.pdf) +describing the challenge can be found in the docs directory. -Notify was a crate I hadn't used before so that took some time to understand -and then determine how I wanted to wrap it up. I like the solution that I -came up with because it keeps most of the notify mess contained in one file -with just a little seepage out when it has to be used for monitoring. -One thing I was not happy about was that I had very poor git commiting during -the challenge. I think it was because I was trying to keep my time lower, but -would it really have hurt to spend a little bit of time to commit and give -myself better backups incase of a big problem? Probably not. +## Platform ## +This was created on Ubuntu and was only tested there. It should +work on most other platforms, but without testing it, I do not +know for certain. -This let me work on and understand rust async. I had read the rust book and -the tokio tutorial completely before doing this challenge. It wasn't that -bad. It reminds me of coding for threads a lot, which is good, but sometimes -the await gets me because I don't understand where it is blocked when it is -running sometimes, tokio-console helps here, and why calls block or what they -are blocking for. For example, why does tokio::io::stdout().write_all() seem -to block forever? It is given a few bytes to write to out, it should be able -to dump those to the console quickly enough. -Really, i think my problem with the async IO calls was that they needed to -happen in a seperate task and be listening for messages on what to print. -That way they are never able to block a different task. - -Next I think I should checkout the rayon crate, but we'll see what the next -challenge I get is. +## Build ## +To build it just use a standard Cargo install with the current +Rust compiler. Make sure your Cargo is set for Crates.IO as +your registry because it uses several crates from there. diff --git a/docs/personal_review.md b/docs/personal_review.md new file mode 100644 index 0000000..c95a4e4 --- /dev/null +++ b/docs/personal_review.md @@ -0,0 +1,33 @@ +# Review # +I thought I solved the challenge pretty well. I took my time and went back +and refactored and commented well. The overall amount of time I spent solving +it, 17 hours, may be rather problematic. I did have to learn some things +while I was working on it, but it took what it took. + +Notify was a crate I hadn't used before so that took some time to understand +and then determine how I wanted to wrap it up. I like the solution that I +came up with because it keeps most of the notify mess contained in one file +with just a little seepage out when it has to be used for monitoring. Perhaps +I should have fully wrapped the library? It wouldn't have taken much more to +do so, it just didn't seem necessary to solving the problem. + +One thing I was not happy about was that I had very poor git commiting during +the challenge. I think it was because I was trying to keep my time lower, but +would it really have hurt to spend a little bit of time to commit and give +myself better backups incase of a big problem? Probably not. + +Ultimately, his let me work on and understand rust async. I had read the rust +book and the tokio tutorial completely before doing this challenge. It wasn't +that bad. It reminds me of coding for threads a lot, which is good, but +sometimesthe await gets me because I don't understand where it is blocked when +it is running sometimes, tokio-console helps here, and why calls block or what +they are blocking for. For example, why does tokio::io::stdout().write_all() +seem to block forever? It is given a few bytes to write to out, it should be +able to dump those to the console quickly enough. + +Really, i think my problem with the async IO calls was that they needed to +happen in a seperate task and be listening for messages on what to print. +That way they are never able to block a different task. + +Next I think I should checkout the rayon crate, but we'll see what the next +challenge I get is.