Quote from janus007:
- Could you maybe post some code snippets and maybe some class documentation i.e. for the Bars class? I'm just curious to see the level of programming![]()
Just a little note on this. The level of programming is going to be somewhat different than what ordinary programmers might expect.
That is, unless you're a system, performance tuning expert.
The code right now for the "Bars" class works to satisfy 2 very critical requirements.
1. Make it very simple to use them in code. And 2. make them screamingly fast to fabricate from ticks (or minute bars as an optimization).
So I started out with all of this originally with a purist object oriented approach and using interfaces, etc.
That's because the wisdom is to code smart first and then tune for performance after.
Well, it required refactoring those classes repeatedly and the whole object graphs that construct the bars from the ticks so that it squeeze every last ounce of performance from the compiler.
I'm certain that most purists will have questions about "why did you do this? or why did you do that?"
But I will recommend, in general that unless you have specific training and experience in that area, then you primarily assess their worth at meeting the 2 requirements which are, are they fast? Are they easy to use in coding customer strategies?
As an aside, 10 years ago I interviewed for a job as an architect. After successfully passing all the interviews, they took me to the CEO (realatively small company) he asked me only one question....
"Which is more important, satisfying the customer requirements or making the best technology decision when those are in conflict?"
As any good interviewee I tried to tease out of him what his opinion was but he was mute except to repeat his question.
So, I said, "of course the best technology solution".
And he said, we'll hire you but not as an architect.
And that was the end of the meeting.
The Business Manager explained the story behind how he and CEO formerly worked at the same company and had opposite philosophies.
So the (later to become) CEO stuck with the company while the (later to become) business manager left out of disagreement with the company over design/technology decisions.
The result as the the CEO became a millionaire and owner of his own firm while the other works for him as business manager.
And that educational experience nudged me firmly in that direction too. Made me a much better architect too.
So let's please don't overly dwell on the code design but focus on how well it works, and the other things you mentioned like versioning and unit tests.
There's no question the code can improve. But when it comes the engine which has good on the "critical path" let's call it. I want to review all of that myself--any ideas for changes--because that's why this project is called "TickZOOM". Hey maybe let's keep the last 4 capital letters for emphasis.
Sincerely,
Wayne