In terms of deployment and profiles. I have implemented a build of NuBot with the tool Gradle this week - basically implementing 0.9.4 of the roadmap. Gradle offers a DSL language for defining how programs should be run. It’s a very flexible build tool. This means that deployment can be simplified, different builds defined etc. This should provide NuBot with everything that is needed in this area. The JavaVM is already a VM so there should not be a need for containers (I have tested docker for client installs before and found they introduce too much complexity). I will have to look into how to streamline the process. Besides entering confidential information (which can’t be automated), everything can put into a build script. Another option might be offering a cloud solution, but there are complex security considerations around that. Cloud providers now offer the capability to build pre-defined images via tools like Packer.
Good to see community-driven prioritisation of the roadmap. I am more than happy to adapt to it, as I said earlier.
Let me reply in line.
This is work in progress : in particular there is an utility I’ve built that custodians are already playing with that reports all executed orders. Sample output from my operation on excoin : http://pastebin.com/p2NCKq10
@Ben is working on integrating and making it more human-readable.
In terms of roadmap prioritisation this is currently in
0.4.4 : NuBot toolkit release ( trade history, balance history, price-peg execution bot)
I think it makes sense to leave it where it is in terms of prioritisation, cannot be moved much earlier than that.
There is a GUI designed and coded since last summer we can re-use. I never hooked it up as no-one ever asked for one and I avoided adding complexity. In 7 months many thing changed but most of the code/design is still re-usable.
Please take into account that the totality of custodians to date run nubot from the command line on a VPS or raspberry and they won’t be able to use a GUI.
For the above reason I believe that we should leave the “Bots manager UI” prioritised as it is now in 1.0.0 . However, what can be done quickly is another kind of UI :
So this will solve a different problem, probably more useful in the short term : nubot configuration.
Currently to configure the bot the custodian need to configure a json file (or multiple json files)
following this tutorial -> https://bitbucket.org/JordanLeePeershares/nubottrading/src/a59f70b780af8730ba92b99dc2d81e91fc7b7ddf/SETUP.md?at=release/0.1.5
Or they can download the sample.zip configuration file and try edit it and reverse engineer it.
We can build a (stand-alone) UI that does nothing but :
- provide a graphical way to configure the bot, and behind the curtains generates the configuration files for the custodian.
- allow custodians to save configurations and assign a name to each "profile
- provide a “launch bot” button that simply runs nubot with the profile created above.
However, there is no way around it… I believe that custodians must be very aware of what they are doing, and how each parameter they touch will affect the behaviour of the bot.
If you think this makes sense I can add a ticket somewhere between 0.2 and 0.3.
Perhaps the first version should merely contain a start button, a stop button, and the same info that is presently logged presented in the UI. The second version could permit essential options.json settings to be entered in text boxes and dropdowns so that the user doesn’t need to edit options.json directly. A third version might show information about open orders and recently executed orders. A fourth might feature reports on trading history, deposits, withdrawals, transaction fees and profits/loss.
Totally agree, the user interface must be built in iteration and the first logical step is making the tool that generates the .json configuration profiles and allow the user to start/stop the bot.
I can envision endless improvements and iterations (API key verification, logging, multiple bot management, move liquidity across markets, reporting, a graphical tool to model the order book etc.
However, everything but the setup UI must be built after v1.0 , where all protocol changes are ready, otherwise it will just enormously slow down the development process requiring change things in several places when we are not even sure of future directions.
I think a simple web UI to create the json files and to show some stats about the bot would already be sufficient + it would be accessible for the VPS / RaspberryPi people.
I just uploaded some screenshot of the JavaFX UI I built last summer, which can largely be re-used .
Please note that html logs are already in place since 0.1.2
I am running NuBot from a desktop machine. I think I should migrate to a VPS.
Edited original post with changes to roadmap
Edited original post with changes to roadmap
Updated roadmap with new short/midterm priorities
Can we change the roadmap along the way? with motions?
Of course, but please do only for macro items at high level and only when there is a strong disagreement with current priorities.
The release we are currently working on turned out to be a major release rather than a small plugin.
Changed 0.2.0.5 ----> 0.3.0, and adapted overall roadmap.
Stay tuned
This is so cool. I would really like to look a bit further again into using the NuBot in the TLLP client. The greatest problem here is that events that the TLLP client recognizes cannot be communicated with the NuBot (except killing it, changing the config, and starting it again).
Is it planned to implement some interface to modify the config parameters interactively? In particular we would need to specify the fund limits on the fly, since this can happen every 15 seconds.
Wow, the GUI is amazing. The things that are being done here are absolutely MASSIVE and so many people have yet to discover it.
Definetly a feature of parametric order books, can be implemented earlier if needed. how would you imagine it working from TLLP perspective?
However you prefer 
Give me a socket, a memory map, a ProcessQueue or simply reparse the config file from time to time. I just need to tell the nubot that it must not place more than X NBT on the buy or sell side right now.
That s impressive, to say the least…
If nu shareholders can find a way to make liquidity provision a predictably profitable business (which i believe they will), your GUI will definitively democratize it.
Comment here and I’ll try to squeeze it into 0.3.1 : https://bitbucket.org/JordanLeePeershares/nubottrading/issue/707/make-an-entry-point-to-change-maxsell-and
The GUI in NuBot is very nice and highly desirable to attract new users. The merge of NuBot and TLLP would be awesome, but I can see that there are many hurdles to overcome given the different architectures of the two. Happy to be surprised though.