As strictly a programming exercise in Ruby it's not. As professional software development it is, because it's just rehashing something that has already been done, without solving any existing problems, without adding new functionality, without market research as to what the end users need, and likely all done without a strict and formal QA process.
What is your problem ? The original poster was good enough to donate his work for free. He is under no obligation to do "market research". Neither is he under any obligation to adopt any development or QA methods that you deem necessary. If there is a demand, it will be used. If there isn't, it wont. That's how free software works.
Panzerman: You're not getting something very fundamental here. IB-Ruby is not a professional software development project ("professional" meaning "done for money"), and evaluating it by the standards of a professional software development project is absurd. It is an open source project coded by people in their spare time. Nobody is charged to use it; no money changes hands, and I'm certainly not being paid to write it. The license (LGPL) explicitly makes it free to use, copy, distribute, and modify. It is a project given to the community so that all who choose to may collaborate and benefit from one another's work. It is still in the early stages, as the first post made clear. This is not a mature product being sold for hundreds of dollars; it's not even a product. It's a small library, still under development, that could one day possibly be used to make a product. It's as if someone showed you a bookcase that was half built and you said, "It may turn into a fine bookcase, but where is the swimming pool?" Once again, this project is not and was never meant for end users or non-programmers or non-Ruby programmers. As it is not intended to generate revenue, it is freed from the constraint of having to respond to market research. There is a very small group of programmers who will find it useful, but there is a group of such programmers nonetheless. Since there aren't enough people in this niche to support a commercial product, I've chosen to open source it and give it away for free. The SOLE benefit of a Ruby implementation of the TWS API is that it allows one to program TWS in Ruby. (And it's not even the only way to do that; it's just one possible way of doing that.) The benefits of programming in Ruby vs. Java vs. any other language in existence have already been debated extensively to death elsewhere. Google it if you want to know what each side thinks. There is no reason to rehash these debates here. There are many valid reasons to use Ruby, just as there are many valid reasons to use Java or anything else. If you're not a programmer, or you are but you're not interested in using Ruby, that's fine. Nobody ever suggested that you should. Some people are; this is for them, not you. As I said, different situations call for different tools. This thread is simply meant to introduce one more tool for those who choose to use it.
Wrong. Users will being placing trades with real money. What if your interface hangs due to a bug that you could have discovered using a formal QA process and the user can't exit their position? It can cost a trader a lot of money. It would leave them with no recourse since they are using software from some dude who wanted to rewrite the Java interface in Ruby because Ruby is new and cool. At least by using IBs official software, you can be sure that it has been tested extensively, and is backed by a real company. That certainly doesn't guarantee bug free software, but if something horrendous does happen, at least there is potential recourse. Traders, don't ever use this software because the developer just wants to hack code and has little regard for a formal engineering process.
It might have escaped your notice, but what is being provided is a library to be used by programmers. It is not a trading tool. If anybody using the library does not have the diligence to test their application thoroughly there is nobody to blame but themself. We are not talking rocket science here. The TWS API protocol is fairly simple. If there is a bug in the library, the user should be able to fix it and contribute the fix to the project. I use Java and will continue to use Java, but I see no reason why somebody should not use Ruby or Python or whatever else if it fits the bill for what they want to do. If they think Ruby is cool or uncool who cares ?
To each his own... But speed/bottlenecks can be major issues in complex real-time systems... And finding useful code on the web gets things done... Plus a Ruby system presents serious long-term maintenance problems. Great if one values programming more than trading... Otherwise... A serious trading business is a business first... And one has no choice but to stick to mainstream software tools.
It is beholden upon both the provider of the libraries and the application itself to ensure the highest quality of code. You guys seem too cavalier about all this. People will potentially be staking large sums of money on the code that you produce. But hey, it's no skin off your back if a guy takes a financial bath from using software that you developed.
All partially valid however ..... As for the real time aspect, the languages in TradeStation, eSignal and their ilk are probably even more unsuited to complex real time systems, but nobody is banging on about that. My assessment would be that the Ruby implementation would be as robust or probably more robust than these. If the aim is to produce code for individual use or for a couple of people, then maintenance is not an issue - if it's broke you fix it. If you can develop and maintain faster in Ruby or Python and it does the job, then for your business it actually is the professional choice. If you use Ruby because you think it is cool and don't understand the issues, then you deserve what you get. It really irks me that the OP is good enough to donate his work and what he gets is basically abuse for being "unprofessional".
One of the strong points of open source is that you have the whole codebase there in front of you. If you are seriously interested in auditing the robustness or security of the code, you can do so -- unlike the vast majority of financial software, which are closed source products. With closed source software, you just have to take the company's word for it. I guarantee that most of their license agreements are bulletproof enough that you don't have any kind of realistic chance of suing them when their software makes you lose money. The real question is why would you trust potentially large sums of money to a black box system provided by a closed source shop?
QUOTE]Quote from Raul641: If you are seriously interested in auditing the robustness or security of the code, you can do so[/QUOTE] Come on are you serious... if? Your codebase needs to developed within the framework of a software engineering process because of the seriousness potential bugs can have. Don't give me this lazy open source, pass the buck bs! Sitting around at midnight, hacking in your undies while smoking pot, hoping someone else will audit your code is no way to develop financial software. Open source is fine, but it still needs to be managed with the rigor of any other project of this seriousness. That means Unit testing, regression testing, stress testing, functional testing, protoyping, bug tracking, CVS system, code review, buffer over flows, input validation, etc... You get the point, treat this project almost as if it was rocket science.