So the sudoku solver is finished. You can download the executable and the project folder from the Demos section of this site. I think it turned out pretty good. It got me into the technical interview stage but, sadly, that's as far as I got. It's all a learning process though so here are a couple of things I think I learned from creating it.
Robot legs is cool
I'd never heard of Robot Legs before I did this project but, now I know about it, I'll probably use it for most if not all of my ActionScript projects from now on. It was dead easy to use once I got the hang of it and I think it gave my code much better structure than it would have had without it.
Test things. For science.
In future projects, if I can unit test something, then I will. It's a good idea, particularly for working on isolated features that you can strip back to just data in/data out. The parser in Sudoku Solver would have taken me so long to do without unit tests. I did make 2 mistakes in writing the unit tests for Sudoku Solver though, the first was that each test should only have one assert in it. I'd grouped my tests into features so I had one test for the parser that would test the whole thing in one go. This was a mistake, I should have written several tests that each tested one specific part of the parser. This would have made it clearer which part of the parser was causing failures. The other mistake I made with the tests was less a mistake with the test, and more a mistake with the program in general. According to the feedback I received, the solver algorithm wasn't as efficient as it should have been. This probably wouldn't have been very noticeable when running the program normally since the UI will only allow you to solve one puzzle at a time but having a unit test that solved 145 puzzles consecutively really highlighted this inefficiency. I guess it would be a good idea in this sort of situation to have the test output some performance data so I could see where and when it was being slowed up. It's not just about whether the test passes or not.
Robot legs is cool
I'd never heard of Robot Legs before I did this project but, now I know about it, I'll probably use it for most if not all of my ActionScript projects from now on. It was dead easy to use once I got the hang of it and I think it gave my code much better structure than it would have had without it.
Test things. For science.
In future projects, if I can unit test something, then I will. It's a good idea, particularly for working on isolated features that you can strip back to just data in/data out. The parser in Sudoku Solver would have taken me so long to do without unit tests. I did make 2 mistakes in writing the unit tests for Sudoku Solver though, the first was that each test should only have one assert in it. I'd grouped my tests into features so I had one test for the parser that would test the whole thing in one go. This was a mistake, I should have written several tests that each tested one specific part of the parser. This would have made it clearer which part of the parser was causing failures. The other mistake I made with the tests was less a mistake with the test, and more a mistake with the program in general. According to the feedback I received, the solver algorithm wasn't as efficient as it should have been. This probably wouldn't have been very noticeable when running the program normally since the UI will only allow you to solve one puzzle at a time but having a unit test that solved 145 puzzles consecutively really highlighted this inefficiency. I guess it would be a good idea in this sort of situation to have the test output some performance data so I could see where and when it was being slowed up. It's not just about whether the test passes or not.
RSS Feed