Future works after Fall 2017

This is just a temp issue and will be added to wiki eventually

convert all functionality to ajax

I don't know what functionality is not ajax yet, but we need to convert all functionality to ajax, I don't think there are many of them.

design a testable receiver

currently receiver is not testable, we need to make sure our receiver parses the request correctly.

an ideal receiver will return a Dict[str, str] (which is the data structure of our current request.json and request.form) and return a parsed object.

better type hinting with numpy and panda.

We need to keep close communication with numpy and panda team in terms of the type hinting. so far, there is no support for type hinting for numpy and panda at all. the numpy has started a officially supported type stub: https://github.com/numpy/numpy_stubs. There is no action in the panda team: https://github.com/pandas-dev

separate the stateless part of file manager into the `FileManagerModel`.

that will make the untestable part of file manager significantly shorter.

clean up and redesign `LexosFile` class.

I don't think LexosFile class is touched at all in the past few years. I think there has to be some outdated functionality and functionality that is not consistent with our style and ideology.

add `mypy` and `pydocstyle` in to the CI checker.

I think pydocstyle will be doable in one summer, mypy integration will be harder. because mypy has much stronger type checks than Pycharm. I imagine there will not be many technical difficulties. It is just fixing type hinting here and there.

a stricter `requirement.txt`

we need to specify version rules for some of the major package we are using, like numpy and pandas. We don't want to stay on the old version for too long, also we don't want newer version to break our build.

Rewrite Tokenizor

Migrate All Functionality To Receiver and Model System

Migrate Wiki to a doc repo and render it using GitHub page.

See an example for dotnet doc: https://github.com/dotnet/docs

Because of the rendering limitation, automation limitation, and team management limitation of Scalar and GitHub Wiki, me and @scottkleinman decided it better to organize our doc using a separate repo, and use the GitHub page associated with that repo to render the docs.

GitHub wiki lacks the basic automation and team management functionality as a separate GitHub repo:

It cannot review and merge pull request,
One cannot view branches of the wiki repo. This makes managing wikis really hard. For example, people cannot find docs for older version of lexos and many other issue related to keep the docs in sync with the latest lexos release, not the current lexos master (the development branch)
It can only render github markdown, which is consice but still not full featured. For example it does not support rendering mathematical formula, which can be important for in the margins.

currently a good rendering engine is hexo this engine is fully written in JavaScript, which @scottkleinman should be familiar with. Here is some of the very useful plugins:

hexo-toc for rendering the table of content in hexo
hexo-math for rendering latex in hexo You can find more useful information here: https://github.com/hexojs/awesome-hexo

Unfortunately hexo by default is used for blogs which means that it doesn't support hierarchical structure by default, however our docs needs to be structured, for example back-end developer guide should be under developer guide. I think we can easily twick the structure to change that.

I have not tried or heard of any website rendering engine written in python.

WheatonCS / Lexos