Moving personal review and adjusting README.
Just making the project a little more tidy.
This commit is contained in:
parent
84be854186
commit
fe7537f238
38
README.md
38
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.
|
||||
|
33
docs/personal_review.md
Normal file
33
docs/personal_review.md
Normal 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.
|
Loading…
x
Reference in New Issue
Block a user