I'm planning to make a few modifications to jstock and wanted to know if you'd be interested in accepting the changes. If you're interested in them, I'll try and do them bit-by-bit and submit patches.
1) At present, it seems that different parts of jstock (eg the main form, the stock indicator etc) each create their own RealTimeStockMonitor. If that's right, that seems a bit inefficient - I'd have thought there should be one, which different parts of the program access. This would also be necessary for my next point.
2) At the moment, if (say) Yahoo does not support the stock code, jstock's behaviour is not that nice. I would like to change it so that the "Board" property of Stock is properly supported and used. So "board" (or maybe a new field "server" if you prefer) means "where to get price info"...and a "manual" board could also be supported. That way I can manually enter the price for certain stocks.
3) There is a strange relationship between StockInfo and Stock that I don't understand. What is the purpose of StockInfo? Initial attempts to add the "Board" behaviour showed that Stocks are often converted to StockInfo and visa-versa, with the remaining information in "Stock" often being lost.
4) Why is the "user defined" list treated so differently? There are several customised lists and functions which are used to keep those Stocks (or maybe StockInfos) which have been user defined. What is wrong with a simple boolean on Stock which describes whether it has been automatically created or user defined?
5) I would like to extend the history behaviour, so that I can keep a local copy of the stock price histories. This would be useful for manual entries and also for stocks where the yahoo service is not reliable. My plan would be to keep a local .csv as is done for caching at present. But the local copy would be stored permanently and intelligently updated when new price information is available (either because a whole history is obtained, or because a new price has been obtained from yahoo, or when a new price is manually entered).
Thanks for the suggestion. Having a single RealTimeStockMonitor, will make the code base complicated. Take a scenario, if I were remove MSFT stock from stock watchlist, should I remove it from RealTimeStockMonitor as well? Will other pages need such information?
As you can see, we will soon build up unnecessary dependencies among multiple pages. This will increase code complexity.
To choose among code simplicity and minor run-time efficiency improvement, I would rather choose "code simplicity".
A useage count would be a very easy way to deal with this situation.
I very much agree with code simplicity. However, this isn't just a minor run-time efficiency - it will cause several extra http server transactions. Moreover, with a manual price input, it will have to "ask" the user several times over!
Oh, and the useage count would not introduce dependencies among multiple pages. To do so would clearly be terrible code.
Having to support multiple different stock servers is in fact difficult. The main difficulty is, different stock servers are using different stock code. For instance, currently, we are migrating India stock market to use Google Finance feed instead of Yahoo! Finance feed : http://yccheok.blogspot.com/2013/10/whats-upcoming-plan-for-jstock.html
However, Yahoo Finance is using completely different stock code from Google Finance's. For instance, Yahoo Finance is using TATAMOTORS.BO, whereas Google Finance is using BOM:570001
Our current strategy is using Factory method.
This method is proven. Hence, we have no plan to add "stock server information" as the property of Stock class.
Manual pricing is interesting. As I do get such request once a while. However, at current level, if we were to implement manual pricing feature, I'm more interested to discuss how the UI high-level flow (From end user perspective) should be. Once we are clear on the UI high-level flow, only we can start discuss on the detailed implementation.
I wasn't proposing multiple servers per stock, so the stock code problem isn't relevant. Just different servers for different stocks. The factory method is fine - the problem is that as far as I can see it isn't really used - there is only ever one server used.
You can view StockInfo as the lightweight version of Stock, where it only contain Code and Symbol member variables. The reason we are having such data structure is that, in certain situation, we are only concern about Code and Symbol, but not other information. Having to create Stock again and again seems cumbersome. That's why we introduce StockInfo.
OK, I can see that for some situations. I guess my problem is the "StockInfoDatabase". It is this which gets written to disk (stock-info-database.csv). Hence things like "Board" and "Industry" don't get saved/restored. I guess this is because Yahoo doesn't supply these things when the StockInfoDatabase is created but in general I don't see why the "StockDatabase" doesn't need all the "info" which a stock has.
So...what about having a StockInfo (which contains all the permanent infos of a Stock - name, code, industry, board, (server!?)). Then Stock as a StockInfo (not all it's own copies of the same information) and then the dynamic information like price?
"Why is the "user defined" list treated so differently?" -> I don't understand on this. Can you provide some examples?
Have a look at StockInfoDatabase.
Internally, that keeps two lists, but one set of Maps etc. Then there are a bunch of functions like:
Most ugly, is that before the StockInfoDatabase is written out to disc, the database has to be sort of split into two with various copy operations and so on (see the code in MainFrame!!!)
This complex code all seems to be to avoid any automatic updates of the stock list overwriting the user defined ones.
I'll have a tidy up and submit a patch for you to see what I mean.
I can't really recall what are the main purposes behind. But you're right, one of the main purposes is
is to get "stock-info-database.csv" untouched, and only "user-defined-database.csv" touchable.
I'm more than happy to receive contribution from you. I think migrating the code base to bitbucket, will make contribution easier (Sending patch through email is cumbersome way).
I think I will stop job on my hand, and perform migration right now...
I had complete migration from SourceForge to GitHub.
I highly encourage you to fork, and make whatever code modification you wish to, according to your own needs.
If you feel certain changes might be useful to JStock (Like cleaner code for StockInfoDatabase), just feel free to send me a pull request. I will review those changes, and merge it into the repository.
If you refer to
It seems that we already have similar feature : save and load stock history price from disk.
Indeed - I'll work with that.
Currently, the urgent fixed needed by JStock is https://trello.com/c/3Bicl0kM
If you think you can provide such patch to overcome the faced problem, I'm really appreciated that.
p/s I realize SourceForget to not suit for code collaboration. In short term, I might migrate the code to BitBucket, while using SourceForget to host download files.
Sorry - for the time being I need to concentrate on getting JStock to be usable by me! There's no motivation to work on code which I can't use for my own requirements! Also, I don't like the cloud storage thing anyway....I guess I don't trust google enough.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.