Items which we may be able to weave into the conversations include:
- Analyzing options; trade-offs between viable solutions to problems and parts of problems.
- Architecture/design/implementation choices.
- Evaluation criteria for various choices
- readability / maintainability
- ease of expressing a solution
- performance
- cost
Even it it doesn't pan out to my fullest desire, I hope that one or both of my kids might learn something useful and enjoy some "geek time" with me.
The initial program I thought of is a Sudoku puzzle solver. A number of us in the family like to work the puzzles at times (some of us more than others).
Here is a link to my initial stab at the well commented Sudoku solver program.
https://drive.google.com/file/d/0B0GbWl6CZQ6lQlZ4S0NHNWpVWVk/view?usp=sharing
This link is to a zip file on my Google Drive containing a Eclipse 4.5.1 project. You can extract it and import it into an Eclipse workspace. There is a README with some hopefully helpful setup info if needed.
[2016/3/15] Below is a stack based solution with some changes for clarity (in many cases compared to the prior recursive version) and has heavy use of JDK 8 functionality including use of "default" in interface definitions and more stream/lambda examples. I'm sure some of my lambda related code could still be cleaned up - probably with use of method references in some places.
https://drive.google.com/file/d/0B0GbWl6CZQ6lZzh4TVl4a3dUOUU/view?usp=sharing
For this particular program, I think some of the conversations might include:
- mutable versus immutable data
- data structure selection
- object orientation design
- serial versus concurrent/parallel processing
- Java 8 "functional programming" features
- solution strategies
- brute force
- backtracking
- recursion versus stack based implementation
**
[2016/05/29] As a side note, simply replacing regular streams with parallel streams had a substantial negative impact on the performance. This was on on a 4 core i5 based system running at 1.70 GHz with Windows 7 x64. Maybe an improvement could be made with some effort but it will take a bit more work than just adding "parallel" in a few places.
**
I'm starting to think about what type of programs might be fun to work on next. Maybe a web application could be interesting but I think the focus would be more on the supporting technology (i.e. container and frameworks). Maybe we will make that decision together.
[2016/04/03] Somethings to note, code reviews are a good thing - would have caught a number of my own documentation mistakes in this code which I need to fix. A code review involves one or more other developers who read the code while looking for errors in logic, code documentation or deviations from some coding standards. Finding the logic/documentation errors is the best code review usage and has a better chance of working if the developers have some artifact the the logic was created from which can be referenced - probably a design document, use case or diagram of some sort. Deviation from coding standards is better identified with other software which can be integrated into appropriate places in the chain of software development events. One of those events might be checking the files/changes into a source control system - something that is important but I am not discussing here. Creating unit tests are another possible way to catch logic errors if the tests are created based upon the desired true outcome (requirement) versus the actual code/logic which was implemented. Do some research into Test Driven Development (TDD) for more info in this area. From a pragmatic standpoint, taking a break from a long coding session and coming back to it after a couple hours to carefully review it again can go a long way to catching your own mistakes (of all types) before others find them.
Deuteronomy 32:2New International Version (NIV)
Let my teaching fall like rain
and my words descend like dew,
like showers on new grass,
like abundant rain on tender plants.
Thanks for reading!
Scott
No comments:
Post a Comment