Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Unlisted stock / History

Developers
Chris Kemp
2013-11-27
2013-11-28
  • Chris Kemp
    Chris Kemp
    2013-11-27

    Hi,

    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).

    Any thoughts?

    Thanks, Chris

     
  • yccheok
    yccheok
    2013-11-27

    Hi Chris,

    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".

     
    Last edit: yccheok 2013-11-27
    • Chris Kemp
      Chris Kemp
      2013-11-28

      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!

       
      • Chris Kemp
        Chris Kemp
        2013-11-28

        Oh, and the useage count would not introduce dependencies among multiple pages. To do so would clearly be terrible code.

         
  • yccheok
    yccheok
    2013-11-27

    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.

    https://sourceforge.net/p/jstock/code/ci/default/tree/src/org/yccheok/jstock/engine/Factories.java

    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.

     
    • Chris Kemp
      Chris Kemp
      2013-11-28

      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.

       
  • yccheok
    yccheok
    2013-11-27

    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.

     
    • Chris Kemp
      Chris Kemp
      2013-11-28

      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?

       
  • yccheok
    yccheok
    2013-11-27

    "Why is the "user defined" list treated so differently?" -> I don't understand on this. Can you provide some examples?

     
    • Chris Kemp
      Chris Kemp
      2013-11-28

      Have a look at StockInfoDatabase.

      Internally, that keeps two lists, but one set of Maps etc. Then there are a bunch of functions like:

      removeAllUserDefinedStockInfos
      removeUserDefinedStockInfo

      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.

       
      • yccheok
        yccheok
        2013-11-28

        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...

         
      • yccheok
        yccheok
        2013-11-28

        Dear Chris,

        I had complete migration from SourceForge to GitHub.

        https://github.com/yccheok/jstock

        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.

        Good luck!

         
  • Chris Kemp
    Chris Kemp
    2013-11-28

    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.