As mentioned in a different post, I'm not a teacher but I do enjoy teaching my kids things. Often this is computer related stuff. Since my son is learning Java at school, I will use that as the initial
basis for some teaching opportunities. He still hasn't learned a number
of key items yet but he will hopefully be ready for this by the end of
the year. My idea for teaching is not the standard read a book and write some tiny bit of code to learn basic syntax/idea. Instead, I am going to write some relatively small (probably < 2000 lines of code) programs which are highly commented. The comments will consist of application specific comments but more importantly will include "talk points" about why I did something or how I could do it different/better. We can then walk through the program itself together and discuss how/why it works.
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
I will also try to convey various good/best practices and various things that should be avoided. I am hopeful that he will take the opportunity to try experimenting with the examples as well.
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
- recursion versus stack based implementation
From a longer term perspective, I might try to create or discuss implementations in other languages/technologies. This might provide me an opportunity to learn some new things at the same time or brush up on some rusty skills. Some initial thoughts on this include: C, C++, Scala/Akka,Erlang, Scheme/Lisp/Clojure, JavaScipt/CoffeeScript/TypeScript.
**
[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
