Good find. I checked this out and it looks good but I don't see where he handles the restart of TWS. I posted a message at the bottom of his page. Based on forums I read that only the Java version reliably and close out the dialog boxes the TWS pops and for login, etc. to seamless restart TWS automatically (hands free) if it fails. I consider that an absolute requirement. So my choice of Java isn't due to the language but only due to a lot posts that show the Java API for IB is more reliable at reconnecting immediately after any outage. Wayne
Folks, Please allow me to just express my appreciation to everyone for the encouragement and great ideas on these threads. Unfortunately, the flu bug got me. So that has slowed my progress because loved ones keep dragging me from the computer back to bed. It continues to be exciting to think how awesome it will be when someone uses TickZOOM software to make money that improves their own life or someone else's through generosity. That's what keeps me pumped about this project and determined to keep it going full blast. Again, thanks for your patience. Here's a little update. The website has a better, more organized setup now. I cleaned up a list of "known defects" in the code and setup up better logging & trace messages so you can send a log file if you have an issue and get it resolved more quickly. Also, I'm about 70% complete getting stuff the other developer needs who is working on the IB connection. I've been working on how to do the documentation also. In the Java world we have JavaDoc and Xref. It seems Sandcastle is the equivalent for C#. So I'm looking into that. And may need to figure a way to integrate it into the website. Does anyone have suggestions who's got more experience with documenting C# code? Many people has register at TickZOOM. That's exiting. Thanks everyone for sticking with this. Sincerely, Wayne
FYI, the registration page at www.tickzoom.com says email is optional but it really isn't because (due to spam issues on the wiki) if you register without verifying an email, then you still don't have any rights on the site. Fortunately, only a few people left their email address off. Sincerely, Wayne
Re: that C# IB-API library. I tried downloading his library and running the test application that comes with it. If the IB/TWS connection is broken I see the message from the callback saying that happened ("Connectivity between IB and TWS has been lost.") and when that connection is restored I see another callback message ("Connectivity between IB and TWS has been restored - data maintained.") - and the quotes start coming into the test application again. Is anything more than this needed ?
Open source and free is good, but from my experience with opensource: - Free Open source project have lots of contributions. This can cause nightmare when you upgrade the core that breaks the link to modules: modules developers often abandon their project and the average guy is left with a broken software. - Core developer might loose interest in the project. - Free open source project are often badly documented, and anarchic. - Developers are arrogant: "Fix it yourself or shut up". Just keep this in mind before making the final decision. There can also be commercial open source.
Excellent. What about the nightly disconnect? Does it automatically reconnect? If so, then it is ideal! If that all works then it will be a snap to integrate it with TickZOOM to have it sending ticks to the black box server or even the GUI app for real time charting. Wayne
Has anybody seen any C# iqfeed or eSignal? Is eSignal out of style now? Also, someone expressed interest in working on the TREE tick data storage and integrating it into TickZOOM, I agreed but haven't heard back. Until they confirm, that's still open and important. Remember, or maybe you saw it on tickzoom.org. We have rewards planned for those who contribute code to the project. Sincerely, Wayne
Koros, your wisdom impresses me. It has become clear that open source is the way to go for this project. But allowing those other risks that you mention to happen, in my view is not acceptable so your are 100% correct. A balance is needed. Just to reiterate or clarify, my plan is to work in this project myself full time starting within 1 or 2 months so that the software continues to grow and innovate. I hope everyone sees my commitment by setting up a professional website and by spending most of my holiday glued to the PC working on prepping the code for public release. Sincerely, Wayne
Koros, I have seen the same thing happen. The OS projects people always mention as successes are actually 1 in 100 or maybe 1 in 1000. Just look at the thousands of projects like you describe on sourceforge alone. Anyway, to mention this issue in particular, my plan is to offer a major benefit to "module" developers as you call them to contribute their code to the central TickZOOM project. The reason is because I'm almost a fanatic (ask my coworkers) about automated regression testing. I'm always tinkering with and improving my automated regression testing tools (just like the innovation with TickZOOM) to make them faster, more resilient, quicker and easier to debug when tests fails, etc. However, while all the source of TickZOOM itself will get released, the regression testing code will remain closed and proprietary and never for sale to anyone at any price. If anyone wants proof, I'll happily show the code coverage % reports, the test pass reports and even demonstrate one or two of them in detail by video. Here's the point of all this. It seems clear, and only makes sense, that programmers LOVE the fact that TickZOOM will serve as the Q.A. and testing department for their code. Most programmers prefer to develop new code than deal with the hassle of testing and retesting. Furthermore by all the "modules" at TickZOOM and integration and regression tested, anytime something does break it will be identified immediately and fixed just as quickly. FYI, in the near future, TickZOOM will have automated nightly builds setup to run and make sure any new code compiles and passes all the regression tests. Anytime someone actually, finds a bug then first a new regression test will be created to test for that error and recreate the defect. Next, the defect is fixed so as to pass the test. That way, an automated test exists forever from that point to always verify that bug never recurs due to changes in the future. Again, it can never be emphasized enough how critical top quality thoroughly tested, official releases from TickZOOM will be. In contrast, the risks of plugging a bunch of "modules" together that could break and possibly at the very worst timing and without any support to fix it is, frankly, unthinkable unless you, the reader, happen to be a skilled programmer and you take testing seriously. Please send any feedback on this plan. Sincerely, Wayne