The Game of Life
Last weekend the good friends of mine were organizing great event, CodeRetreat in Odessa. I supposed to be there, but due to bad luck I missed that. Nevertheless, I was very interested in CodeRetreat idea, so I followed up the materials and learned a bit about it.
CodeRetreat is about the software craftsmanship. You focus on 4 principles of Simple Design, work in pairs through the series of time boxed sessions, each time starting from scratch (yes, all code produced on previous sessions is destroyed with no mercy). All of that aim one simple goal, became a better developer. For the implementation they selected famous Game of Life. The cellular automata, with simple rules but given very interesting results and foundation for numerous researches.
To do not stay with my misery of missing event, I decided to “play” game of life at home. Trying to follow the rules of sessions, I started to write some JavaScript code. It’s even hard to tell, how much fun I had during this implementation.
Tests, code, tests
TDD is very recommended way of development in CodeRetreats. I love TDD and fortunately the game of life is very TDD friendly. It’s all about the logic. Logic seems to be very simple and easy describe with tests. For my JavaScript testing I used to use Jasmine testing framework. Jasmine is BDD tests style, which was a little difficult to me at very beginning, but not I tend to write all my tests with BDD style.
I’ve spent first two sessions for idea elaboration. At the end third session, I got something working. As I said, the process of writing that code was so fun to me, that I even decided to gist the code I created so far.
My big disappointment after was that code is actually not working.
Understanding the problem
Even if I had good tests suite, that showed my code works as expected the game was broken. And the issue is that I didn’t understand the domain good enough. It took me 4 sessions (about 4 hours) to finally understand the game.
I proved it once again for myself, there are no perfect code; the code you created at first time is probably broken (unless you understand the domain perfectly, but it’s rarely happen in reality). It’s OK to completely remove the code you created before and start from the beginning. And with each iteration you moving faster and faster.
Knowing the requirements I was able to create good test suite.
Algorithms and data structures
During the implementation, you have to recall some basics algorithms and data structures. My initial implementation was based on usage of 2-dimensional arrays. It seems to be very natural fit, since the game is happening on orthogonal grid of square cells. But during the implementation of cell replication logic I suffered that design.
Index arithmetic is very tricky and error-prone stuff. So, after several tries I switched from array into the list of cells, each cell holds it’s state and position. The tick method of became very elegant, containing 2-pass procedure - one to calculate next state of each state, second is to switch to new state.
Again, I was so happy with code. It looked very readable as for me, without nested cycles and if-else statements.
Visualisation
You can really understand if something works or not, only if you see it in action. I had to have some UI to see, how game is actually working.
I’ve created very simple HTML based UI. The number of div’s which change it’s state, depending on cell state (alive or dead).
The visualization of results is very important part. It’s only then I tried to run the game on 64x64 square, I realized that performance of my implementation is so terribly poor. It runs very slowly on Chrome, it makes IE10 die.
It means that, all beautiful code, tests, specs and so on - is almost useless, than it comes to performance. My 2-pass algorithm, with a simple implementation is not “production” ready, if we talk about some real software. Unit tests are usually done on smaller sets of data. Visualisation and trying the things on larger set of data opens up the reality.
Conclusions
As I already said, it’s so much fun. It makes you feel like “back to roots”, forget about your enterprise stuff and do some real work. Besides it’s great TDD exercise. It’s probably to big to be called code kata, but it is still great for sharping an axe. Focusing on simple design is important. But making things “visible” and running them in real mode is vital.
The most important conclusion for me is: I’m still newbie developer, with so many areas to improve.
Last weekend the good friends of mine were organizing great event, CodeRetreat in Odessa. I supposed to be there, but due to bad luck I missed that. Nevertheless, I was very interested in CodeRetreat idea, so I followed up the materials and learned a bit about it.
CodeRetreat is about the software craftsmanship. You focus on 4 principles of Simple Design, work in pairs through the series of time boxed sessions, each time starting from scratch (yes, all code produced on previous sessions is destroyed with no mercy). All of that aim one simple goal, became a better developer. For the implementation they selected famous Game of Life. The cellular automata, with simple rules but given very interesting results and foundation for numerous researches.
To do not stay with my misery of missing event, I decided to “play” game of life at home. Trying to follow the rules of sessions, I started to write some JavaScript code. It’s even hard to tell, how much fun I had during this implementation.
Tests, code, tests
TDD is very recommended way of development in CodeRetreats. I love TDD and fortunately the game of life is very TDD friendly. It’s all about the logic. Logic seems to be very simple and easy describe with tests. For my JavaScript testing I used to use Jasmine testing framework. Jasmine is BDD tests style, which was a little difficult to me at very beginning, but not I tend to write all my tests with BDD style.
I’ve spent first two sessions for idea elaboration. At the end third session, I got something working. As I said, the process of writing that code was so fun to me, that I even decided to gist the code I created so far.
My big disappointment after was that code is actually not working.
Understanding the problem
Even if I had good tests suite, that showed my code works as expected the game was broken. And the issue is that I didn’t understand the domain good enough. It took me 4 sessions (about 4 hours) to finally understand the game.
I proved it once again for myself, there are no perfect code; the code you created at first time is probably broken (unless you understand the domain perfectly, but it’s rarely happen in reality). It’s OK to completely remove the code you created before and start from the beginning. And with each iteration you moving faster and faster.
Knowing the requirements I was able to create good test suite.
Algorithms and data structures
During the implementation, you have to recall some basics algorithms and data structures. My initial implementation was based on usage of 2-dimensional arrays. It seems to be very natural fit, since the game is happening on orthogonal grid of square cells. But during the implementation of cell replication logic I suffered that design.
Index arithmetic is very tricky and error-prone stuff. So, after several tries I switched from array into the list of cells, each cell holds it’s state and position. The tick method of became very elegant, containing 2-pass procedure - one to calculate next state of each state, second is to switch to new state.
Again, I was so happy with code. It looked very readable as for me, without nested cycles and if-else statements.
Visualisation
You can really understand if something works or not, only if you see it in action. I had to have some UI to see, how game is actually working.
I’ve created very simple HTML based UI. The number of div’s which change it’s state, depending on cell state (alive or dead).
The visualization of results is very important part. It’s only then I tried to run the game on 64x64 square, I realized that performance of my implementation is so terribly poor. It runs very slowly on Chrome, it makes IE10 die.
It means that, all beautiful code, tests, specs and so on - is almost useless, than it comes to performance. My 2-pass algorithm, with a simple implementation is not “production” ready, if we talk about some real software. Unit tests are usually done on smaller sets of data. Visualisation and trying the things on larger set of data opens up the reality.
Conclusions
As I already said, it’s so much fun. It makes you feel like “back to roots”, forget about your enterprise stuff and do some real work. Besides it’s great TDD exercise. It’s probably to big to be called code kata, but it is still great for sharping an axe. Focusing on simple design is important. But making things “visible” and running them in real mode is vital.
The most important conclusion for me is: I’m still newbie developer, with so many areas to improve.