Giter Club home page Giter Club logo

drunken-octo-avenger's Introduction

Introduction

This is a turn-based Go server. We are mostly writing this for fun and as practice for other web applications.

Setup

Run the setup script, give the python version you wish to use as the only argument.

source setup.sh 3.4

This will create a virtual environment, activate it, and install all of the dependencies. We also have a setup script for users of fish, simply run this as . setup.fish.

manage.py

Once you have done that, a good place to start is to look in manage.py and run python manage.py --help, you can also get help for a specific command, for example python manage.py test --help.

database

Run python manage.py remake_db to create the database (by default it will appear in a directory named generated which is excluded from the git repo).

Generally you can run python manage.py db upgrade to upgrade the database to the most recent version, for example you may have to do this following a git pull. You can see the current version of the database with python manage.py db current.

compilation

So far the only code that needs compiling is the coffeescript in app/coffee (and at time of writing, the resulting Javascript is still included in the repo, so unless you're editing it, you shouldn't need to compile even that). In the repository root directory, run

python manage.py coffeebuild

running

(from virtualenv)

python manage.py runserver

Access the local server at http://localhost:5000 by default (other domains will need to be set in config.py to avoid confusing the login system).

testing

Just run python manage.py test to run all of our tests with coverage analysis. You can run more specific tests, for example whilst developing, rather than repeat everything here, just checkout the manage.py file.

testing against a remote server

For notes on running browser automation tests against remote servers, see the markdown file in app/browser_tests.

Javascript code

To enable the coverage options for Javascript, run a local server as above and open http://localhost:5000/static/tests/tests.html. This may later become the only way to run the tests if we start doing clever things that get the server involved in JS testing.

If you don't care about coverage, you can also just open the local file app/static/tests/tests.html in your browser.

drunken-octo-avenger's People

Contributors

karlorg avatar allanderek avatar

Watchers

 avatar  avatar

Forkers

allanderek

drunken-octo-avenger's Issues

Pass should also require a confirmation

To avoid accidental passes.
It's also possible that we could have pass and resign as playable buttons just like a stone move, and then we just have the two submit buttons, and submit works the same for pass and resign as it does for stone moves.

a way to remove your proposed move

maybe clicking off the board could remove a new stone, if you've placed one? Helpful, or surprising? Maybe just add a new button, eg. at the bottom right, that clears the proposed stone.

Development temporary database

Provide a clean way to use a temporary database whilst in development mode. The problem I have at the moment is if you make a change which requires a database migration, you don't really want to migrate the local database (or spend time writing the migration) until you're sure of the exact nature of the new database schema that you want. Hence in the meantime what you would like to do is be able to run the current state of the code with a new database. I'm typically doing this:

$ cp generated/db.sqlite current.db.sqlite

Then modify the code as much as I like and develop it, until I have the feature working. Then I can work on my new feature, get all the tests passing and such. Then develop the migration, then:

$ cp current.db.sqlite generated/db.sqlite

Check the migration and tests work and then delete the current.db.sqlite.

So basically I think I just want to codify this practice in the manage.py file.

Nicknames for Persona users

To avoid showing users' emails to other users, allow (and require/strongly suggest?) users to set a nickname to display to others.

Maybe set a default nickname that's just the local part of the email?

Back and Forward buttons for game view

Rather than just the drop down menu, which I'm not suggesting we get rid of, we could have left and right arrows to move back and forward through the game.

Notifications content

I'm not keen on the way we display notification content using 'safe'. Currently all the content of a notification is controlled by us, but it would be easy to forget that if we allow other content. For example, we might wish to say "Your game with {} has ended".format(opponent_name) in which case we'd have to worry if the opponent name contained something bad.

So, what I would like is to simply have more information stored within the notification itself. For example we could have 'associated action' which would mostly be to view a game, but could be something else.

JS tests sometimes fail for no apparent reason

Sometimes loading tests.js shows failures in 'clicking multiple points moves black stone'. Checking out an earlier version of the repo and then switching back to the current one seems to fix this, but I can't see why it happens. None of the relevant files are untracked as far as I know.

Color Enums

There are Color enums defined in both 'go.py' and 'go_rules.py', this cannot be good? They are defined to be the same, but surely that is just asking for someone to change one and not the other.

Browser tests not under coverage

Running just the browser tests under coverage shows that they're not being counted toward test coverage. Not sure why; maybe the COVERAGE_PROCESS_START environment variable isn't being propagated to whatever subprocesses are running the test server?

Convenient migration test

If we make an enhancement which requires an update to the database then we currently only test from a completely re-made database, not one which has been migrated from old data. Which is of course the situation we would do on the live server.

So, it's great that you can do a python manage.py db migrate, then edit the migration script and then python manage.py db upgrade. If you then play about with it locally you will manually testing against a migrated database. But if you do a python manage.py test, the test database is completely re-made from scratch. So the automated tests are not testing any migration.

So a couple of things would be nice. The first is a way to manually fiddle about on a completely re-made database, without destroying the current local one. Something like python manage.py runserver --brand-new-db. This would be useful when developing a new feature which requires a change to the database but you don't want to bother with a migration script just yet because you're not quite sure of the exact update to the database that you wish to make is. You're experimenting.

Secondly, we would like a command like python manage.py test_migration which did something along the lines of

  1. Create a new temporary local database file at the migrated from version
  2. Populate it with some data.
  3. upgrade the temporary local database using the migration script
  4. Run our tests on the upgraded database

Comments which do not validate

Just a reminder to myself to have a better look at what happens when the comment form does not validate. Previously, we would return to the game page, with a flashed message about the comment form not validating, but now that it is an asynchronous call we just kind of fail silently.

Check that /shutdown route does nothing on non-Werkzeug servers

Just a reminder, when we have a version of the app with the /shutdown route deployed, make sure that route does not allow random visitors to kill the server.

... and more generally, verify (somehow) that all the testing 'helper' URLs do nothing on a production deployment, which requires working out how to distinguish a production deployment from a staging one.

Finished Games

Finished games should have some description of what happened. In particular it should at least say who won. For an game that finishes with a count, this is perhaps obvious, but for a game that finished by resignation this is not that obvious.

Multiprocessing after all

Random thought I don't have time to follow up on right now:

There was some place in the code, probably to do with running Casper tests I think, where the original version used multiprocessing but I couldn't get coverage to work with that. Maybe multiprocessing could work if we check what functions coverage calls on process startup, and call them manually in the new process?

This is obviously very vague as it's all from memory and I'm not able to look into it yet.

Resign should work as pass.

Currently in the play route, we check if the 'resign' button is used, but we should instead make this work in the same way that pass does. In particular this would mean that would not have a separate notify_user call since this would be handled correctly if the game is ended. Additionally it would mean that resign moves are captured in the SGF.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.