pjurczynski/inmate_kata

Greegko and Piotr are both prisoners, locked in a solitude. There's nothing else left for them other than improving their coding quality together.. 15 minutes at a time.

inmate_kata's Issues

Commit message

Maybe too early, but we can display signal what does the commit is affecting.
My suggestions:

test: ...
implementation: ...
refactor: ...
misc: ...

test - When touching tests
implementation - When implementating tests
refactor - We have a good implementation, but we decided to improve more. In this case we can rise more questions how this refactor is good or not, should be done or not.
misc - any commits which is not related to the problem, like adding typings, dependency update, etc.

on test and implementation commit, we can only touch the relative files.
Also I would restrict to have 1 test and 1 implementation per session, and misc / refactor is unlimited.
But for refactor commits, still should be small steps and not overall changes in one shot. We should focus on how to solve issues in small steps.

Problem: Reverse Polish Notation

Base article: https://en.wikipedia.org/wiki/Reverse_Polish_notation

Prisoner no 010101 (pjurczynski) limited access hours.

Prisoner got detained and can only rent a computer between 22:00 and 24:00 each day.

During the next week due to special circumstances, his public works on the code can happen between 6:00 and 7:00. Although that's not guaranteed, he might also be a subject of corporal punishment during that time.

The pros of the experiment

Let's write some thoughts why the experiment is exciting, why it may have a positive impact, what we learnt from it.

When testcase is not right

How should we handle when one of the participant wrote wrong test?

Single branch or PRs?

I think we may want to go with single branch on this one. Then we can put comments on commits directly and still get the feedback.

I guess PRs would be too much overhead.

The cons of the experiment

Let's write what are the shortcoming, why it's a bad idea and what we dislike about it.

Let's choose a topic

This time I would like to not only create a simple function that can do stuff but actually implement UI through TDD. I have a couple of suggestions:

Safe bet:

• simple calculator with an interface

Almost ambitious:

• again the polish notation, but we should finish it and implement an interface.

Ambitious:

• A parser for the algebraic notation in chess: https://en.wikipedia.org/wiki/Algebraic_notation_(chess) - I would like to evolve it to have an actual interface, maybe with a prompt for "next move"

E2E + Unit Testing + ?

I think that if we want to implement a more complex, more real-life example, then we should also add some e2e tests.

Thoughts?