sixty-north / bark-spider Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 1.0 692 KB

A web interface for Sixty North's software process simulation tools.

License: GNU Affero General Public License v3.0

Python 27.18% CSS 4.56% JavaScript 18.61% Gherkin 2.55% Elm 39.92% HTML 4.33% Shell 2.71% Emacs Lisp 0.13%

bark-spider's People

Contributors

Watchers

Forkers

pombredanne

bark-spider's Issues

Prevent temporary "flashing" of the chart when parse errors exist

Currently, we clear the parse-errors list when we submit new simulation parameters. This has the effect of making the chart visible temporarily since its visibility is based on the emptiness of that list. We should atomically update the list when all requests are complete.

Investigate animation frames for chart timing

Right now we have a 50ms timeout for rendering the chart, but a discussion on elm-discuss indicates that we should look at animation frames for doing this timing.

Support display of multiple simulations

Right now we only show a single simulation. But it's most instructive for people when they can view multiple simulations overlayed. This will require a bit of javascript-fu, but it should be manageable.

Vagrant up can fail to fetch elm packages sometimes

I've seen vagrant up fail to properly initialize systems when it has trouble fetching elm packages. They fail with some sort of handshake error.

I don't know if we can prevent that, but we could try something like a retry mechanism.

Consider typescript

Right now we're using straight javascript, but typescript was pretty nice on fracreg. The downside is that it introduces more complexity for development and deployment. The upside is that we get static typing for javascript.

Create some tests

The JSON api
Basic parameter set CRUD

make.sh fails

When following the instructions to install without vagrant:

$ sh ./make.sh
cat: src/Native/Chart.js: No such file or directory

Find better way to manage the elm.js output

Right now we have to make sure elm.js goes into static/js so that it gets served properly from pyramid. I guess this isn't totally horrible, but it feels a bit hackish.

Consider bower for dependencies

RIght now we're slurping our js and css deps from CDNs. Perhaps this is all fine, but most people seem to recommend using bower to keep copies locally. This worked well for fracreg, so look at it as an example.

Data validation

We need a strategy for validation of values. We should try to prevent them on the client, but we also need to check on the server. For example, if we enter a negative number for "# devs added" we currently get an internal server error...uncool.

Add protractor test for disabled "run simulation" button

We should have a UI test that checks that "run simulation" is disabled when no parameter sets are enabled. This should have been done as part of the initial work on that feature.

Investigate other plotting options

Chart.js was easy to set up, but it seems a bit limited. For example, there doesn't seem to be a way to de-clutter to X-axis. There are plenty of other options out there, and the basic plumbing (i.e. the JSON interface to the simulator) won't need to change.

Add AGPL license

Simplify concurrency handling

Right now we have a somewhat complex implementation for performing simulations in the background. In views.py we use a multiprocessing pool to run simulations in separate processes. The deferred results for simulation are passed to SimulationDatabase.add_results() which expects to receive a callable that produces the actual results.

One downside of this is that, since we use multiprocessing ourselves, we can't run under web servers that also use multiprocessing. In particular, we can't run under uwsgi. This isn't a showstopper - we can use cherrypy, waitress, etc. - but it's worth noting.

Another is that it feels a bit too manual. It would probably be better to use a task-distribution queue like celery to handle simulation runs. This way we can scale up simulations as much as we want. The calls to send work to celery workers should provide the blocking IO point for web servers to handle concurrent calls, i.e. while waiting for simulation results to be executed the web server can process more requests.

Anyhow, this isn't necessary right now. We don't have any load to speak of. But it's probably a better design that the current one.

Consider elm-visualization for charting

This could be an alternative to chartjs that's a) more powerful b) more complicated and c) in pure elm.

https://github.com/gampleman/elm-visualization

Look at elm-plot

This was recommended on elm town. Not sure which they're talking about. Look at episode 4 notes when they're available.

Support more expressive Schedule definition

Right now we have very limited support for dynamic schedules. Essentially you can only add a certain number of devs at one point in the schedule's run. We should have a more expressive means.

We can't just let people enter arbitrary Python code, of course, so we'll need to devise some sort of DSL.

Test failure: test_simulate_route (bark_spider.tests.SimulateRouteTests)

$ python -m unittest bark_spider.tests
F
======================================================================
FAIL: test_simulate_route (bark_spider.tests.SimulateRouteTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/rjs/dev/bark-spider/bark_spider/tests.py", line 108, in test_simulate_route
    expected)
AssertionError: {'ela[19 chars]3', '0': '0', '7': '7', '2': '2', '4': '4', '1[477 chars]'1'}} != {'ela[19 chars]3', '9': '9', '0': '0', '7': '7', '4': '4', '1[478 chars]'1'}}
Diff is 1637 characters long. Set self.maxDiff to None to see it.

----------------------------------------------------------------------
Ran 1 test in 0.782s

FAILED (failures=1)

I haven't investigated further.

Embed built chart.js in the repository

Right now our instructions say to build the elm chartjs extension each time we install. We could just keep a built version in the repository rather than building it...this would de-complicate it quite a bit.

We would need to keep around instructions for building chartjs if/when it gets updated.

Edit fields overlap field labels

This screenshot is on Safari 9.0.1

Two param sets with same name cause problems

If we have two param sets with the same name, then only one of them gets shown in the output. We can perhaps just enforce name uniqueness somehow. Or we could use a differet unique ID for the param sets (a GUID).

Interventions should be plugin-based

Part of the plan is to provide interventions as part of the "pro" plan. So they should be provided as a separate package. They should be "self parsing" on some level, I guess.

Persistence of reports?

RIght now the data used to generate the reports come as JSON from the server. The requests are also POSTs of JSON, so there's no unique URL for each report. As such, it might be nice to be able to persist named reports for users.

At the same time, we should consider some unique URL scheme. This way users could just bookmark the report they want.

Missing intervention definitions do not result in a 500 error

If an intervention definition is not found – for example because the interventions have not been installed – any attempt to run the simulator results in an error server side, but no error is apparently reported back to the client. I'd expect a 500 error of some sort.

$ pserve development.ini 
Starting server in PID 84091.
serving on http://0.0.0.0:6543
2015-11-02 21:20:07,060 ERROR [pyramid_debugtoolbar][waitress] Exception at http://0.0.0.0:6543/simulate
traceback url: http://0.0.0.0:6543/_debug_toolbar/exception?token=62275c7866355c783032795c7865325f4e2e5c786566325c78666127&tb=4428651208
multiprocessing.pool.RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/Users/rjs/dev/bark-spider/bark_spider/intervention.py", line 40, in _parse_intervention
    cls = _interventions()[command]
KeyError: 'add'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 119, in worker
    result = (True, func(*args, **kwds))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/simulation.py", line 27, in run_simulation
    schedule = make_schedule(**params)
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/schedule.py", line 74, in make_schedule
    parse_interventions(StringIO(interventions)))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/schedule.py", line 14, in __init__
    self._interventions = sorted(interventions, key=lambda i: i.time)
  File "/Users/rjs/dev/bark-spider/bark_spider/intervention.py", line 45, in _parse_intervention
    command, line))
ValueError: Unknown command "add" while parsing interventions. (full command=add 100 10)
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid_debugtoolbar/toolbar.py", line 192, in toolbar_tween
    response = _handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid_debugtoolbar/panels/performance.py", line 57, in resource_timer_handler
    result = handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/tweens.py", line 21, in excview_tween
    response = handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/router.py", line 163, in handle_request
    response = view_callable(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 329, in attr_view
    return view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 305, in predicate_wrapper
    return view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 355, in rendered_view
    result = view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 501, in _requestonly_view
    response = view(request)
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 42, in simulate_route
    lambda: _async_simulation(sim_params))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation_db.py", line 15, in add_results
    results = gen()
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 42, in <lambda>
    lambda: _async_simulation(sim_params))
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 24, in _async_simulation
    return result.get(timeout)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 599, in get
    raise self._value
ValueError: Unknown command "add" while parsing interventions. (full command=add 100 10)

Upgrade to 0.18

https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.18.md

New parameter sets should be "open"

When we create a new parameter set, it should be opened and ready for editing. Ideally the name field would be selected and highlighted such that immediate typing would modify the name.

Missing intervention definitions do not result in a 500 error

$ pserve development.ini 
Starting server in PID 84091.
serving on http://0.0.0.0:6543
2015-11-02 21:20:07,060 ERROR [pyramid_debugtoolbar][waitress] Exception at http://0.0.0.0:6543/simulate
traceback url: http://0.0.0.0:6543/_debug_toolbar/exception?token=62275c7866355c783032795c7865325f4e2e5c786566325c78666127&tb=4428651208
multiprocessing.pool.RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/Users/rjs/dev/bark-spider/bark_spider/intervention.py", line 40, in _parse_intervention
    cls = _interventions()[command]
KeyError: 'add'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 119, in worker
    result = (True, func(*args, **kwds))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/simulation.py", line 27, in run_simulation
    schedule = make_schedule(**params)
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/schedule.py", line 74, in make_schedule
    parse_interventions(StringIO(interventions)))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation/schedule.py", line 14, in __init__
    self._interventions = sorted(interventions, key=lambda i: i.time)
  File "/Users/rjs/dev/bark-spider/bark_spider/intervention.py", line 45, in _parse_intervention
    command, line))
ValueError: Unknown command "add" while parsing interventions. (full command=add 100 10)
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid_debugtoolbar/toolbar.py", line 192, in toolbar_tween
    response = _handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid_debugtoolbar/panels/performance.py", line 57, in resource_timer_handler
    result = handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/tweens.py", line 21, in excview_tween
    response = handler(request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/router.py", line 163, in handle_request
    response = view_callable(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 329, in attr_view
    return view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 305, in predicate_wrapper
    return view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 355, in rendered_view
    result = view(context, request)
  File "/Users/rjs/dev/virtualenvs/bark-spider/lib/python3.4/site-packages/pyramid/config/views.py", line 501, in _requestonly_view
    response = view(request)
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 42, in simulate_route
    lambda: _async_simulation(sim_params))
  File "/Users/rjs/dev/bark-spider/bark_spider/simulation_db.py", line 15, in add_results
    results = gen()
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 42, in <lambda>
    lambda: _async_simulation(sim_params))
  File "/Users/rjs/dev/bark-spider/bark_spider/views.py", line 24, in _async_simulation
    return result.get(timeout)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 599, in get
    raise self._value
ValueError: Unknown command "add" while parsing interventions. (full command=add 100 10)

Install without vagrant requires wisp

I found I needed to install a language called wisp. I used:

sudo npm install -g wisp

Simulation timeout

To prevent inadvertent screw-ups and denial of service attacks we should force simulations to terminate after a given timeout, of say 5 seconds.

It may be preferable to run the simulator in a separate process and collect the output over stdin or a pipe.
This makes it easier to kill any errant simulations which timeout without us getting into lots of Python concurrency stuff (ugh!). It will also likely scale better.

REST API should only accept a single schedule at a time.

See #12

We want to change the API so that only a single schedule can be passed in at a time. Each schedule will get hashed, and this hash will serve as the unique ID for the schedule and its simulation results.

Improve error reporting when simulation runs fail

It seem that when e.g. a simulation doesn't work due to a missing intervention, then we don't give very good diagnostics for the elm version. Instead of something useful, we see "BadResponse 400 ("Bad Request")"

Update to elm 0.17

A bunch of stuff has changed. See http://www.lambdacat.com/migrating-from-elm-0-16-to-0-17-from-startapp/

Sort out race conditions in client code

Right now the clients - both elm and angular - request simulation results immediately after requesting the simulation, and they have no retry mechanism. This only works right now, I believe, because the simulation is so fast that results are available effectively instantaneously.

It would be smarter if the clients were able to poll/retry until the results are actually available. Or we might want to investigate something like websockets where the server can tell the client when results are available.

sixty-north / bark-spider Goto Github PK

bark-spider's People

Contributors

Watchers

Forkers

bark-spider's Issues

Recommend Projects

Recommend Topics

Recommend Org