The craftsmanship of the commits in there own right is challenging. I am missing one in which I committed the file creation and the test that does the import at the same time.
Trying to look up how to mock static types or built in is also not trivial.
I learned in this exercise, Python 2 the module is '__builtin__', while Python 3 it is 'builtin'.
Trivial yes, but I see room for improvement AND learned something.
FYI, the concept of deliberate practice... do you think LeBron James still practices free throws, or is that a waste of his time? expertenough.com/1423/deliberate-p...
Trying to look up how to mock static types or built in is also not trivial.: Why do you want to mock a build-in library? Do you not trust that it works?
Trivial yes, but I see room for improvement AND learned something. Nothing is trivial up to the point of actually implementing it. Only time will tell if you actually learned something as it's not a one-time endeavor.
FYI, the concept of deliberate practice... do you think LeBron James still practices free throws or is that a waste of his time? : I didn't say you wasted your time. It just I believe you will have to practice a more pragmatic approach to testing and committing things.
Of course, you have to practice. there is no question about it. But at the end of the day, you have to challenge what exactly do you practice and what realistic goals have you achieved. This is a very fine line between practicing and self-consuming. And in your case, I saw the latter that's why I commented. :@
For mocking built ins, I work on an ETL Integration team, writing unit tests that mock open in Python and read/write IO. At one point this was a pain in the arse.
I love the conversation and don't want to trivialize any concerns you have, FYI :)
I intend to finish/polish this article tonight.
I look at it this like a proof in discrete mathematics. From the base case of what the concept of 1 is, we can prove 1+1=2, then eventually get to calculus or linear algebra.
O no, I haven't done formal proofs since college. I was trying to make an analogy.
I have been TDD exclusive for over 4 months (in both professional and personal projects), yet I had not attempted something like this. In the analogy, I had been playing with high level concepts without 'mastering' the base case.
I feel like even in this SIMPLE example, there are a few things that could be better. To get my commits to look pretty, I interactively rebased.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The craftsmanship of the commits in there own right is challenging. I am missing one in which I committed the file creation and the test that does the import at the same time.
Trying to look up how to mock static types or built in is also not trivial.
I learned in this exercise, Python 2 the module is '__builtin__', while Python 3 it is 'builtin'.
Trivial yes, but I see room for improvement AND learned something.
FYI, the concept of deliberate practice... do you think LeBron James still practices free throws, or is that a waste of his time?
expertenough.com/1423/deliberate-p...
Well I don't agree on all of your points:
Trying to look up how to mock static types or built in is also not trivial.
: Why do you want to mock a build-in library? Do you not trust that it works?Trivial yes, but I see room for improvement AND learned something.
Nothing is trivial up to the point of actually implementing it. Only time will tell if you actually learned something as it's not a one-time endeavor.FYI, the concept of deliberate practice... do you think LeBron James still practices free throws or is that a waste of his time?
: I didn't say you wasted your time. It just I believe you will have to practice a more pragmatic approach to testing and committing things.Of course, you have to practice. there is no question about it. But at the end of the day, you have to challenge what exactly do you practice and what realistic goals have you achieved. This is a very fine line between practicing and self-consuming. And in your case, I saw the latter that's why I commented. :@
For mocking built ins, I work on an ETL Integration team, writing unit tests that mock open in Python and read/write IO. At one point this was a pain in the arse.
I love the conversation and don't want to trivialize any concerns you have, FYI :)
I intend to finish/polish this article tonight.
I look at it this like a proof in discrete mathematics. From the base case of what the concept of 1 is, we can prove 1+1=2, then eventually get to calculus or linear algebra.
Ok, I agree with that kind of proofs you need something more formal. Have you explored Coq?
coq.inria.fr/
or Idris
idris-lang.org/
O no, I haven't done formal proofs since college. I was trying to make an analogy.
I have been TDD exclusive for over 4 months (in both professional and personal projects), yet I had not attempted something like this. In the analogy, I had been playing with high level concepts without 'mastering' the base case.
I feel like even in this SIMPLE example, there are a few things that could be better. To get my commits to look pretty, I interactively rebased.