myrddin/file_monitor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Moving personal review and adjusting README.

Browse Source 
Just making the project a little more tidy.
This commit is contained in:
Myrddin Dundragon
2025-03-25 22:22:19 -04:00
parent 84be854186
commit fe7537f238
2 changed files with 44 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
README.md
View File

@ -1,33 +1,17 @@
# FileMonitor # FileMonitor #
This was a Rust Challenge that I completed in 17 hours. This was a Rust Challenge that I completed in 17 hours.
## Review ## The [document](./docs/rust_coding_challenge_filemonitor.pdf)
I thought I solved the challenge pretty well. I took my time and went back describing the challenge can be found in the docs directory.
and refactored and commented well.
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 ## Platform ##
the challenge. I think it was because I was trying to keep my time lower, but This was created on Ubuntu and was only tested there. It should
would it really have hurt to spend a little bit of time to commit and give work on most other platforms, but without testing it, I do not
myself better backups incase of a big problem? Probably 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 ## Build ##
happen in a seperate task and be listening for messages on what to print. To build it just use a standard Cargo install with the current
That way they are never able to block a different task. Rust compiler. Make sure your Cargo is set for Crates.IO as
your registry because it uses several crates from there.
Next I think I should checkout the rayon crate, but we'll see what the next
challenge I get is.

33
docs/personal_review.md Normal file
View File

@ -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.