lambdabaa / envoy Goto Github PK

Our webdriver test suite

• purges the database,
• starts meteor (and mongo),
• loads database fixtures,
• starts firefox,
• runs test code,
• and posts coverage info

For each test. It takes a long time. We need to parallelize tests or otherwise speed things up so that developers can get faster test feedback.

The easiest ways to make changes, build, and test envoy have (dramatically) diverged from what's recommended in the 0.0.1 README. We should update the material there for the 0.1.0 release.

• Users decks are initially shuffled.
• Users hands start with 6 cards.
• Users can update players' life totals.
• Users can click on cards in their hand and cast them to energy, put them in play (face up or face down), or put them in the graveyard.
• Users can click on cards in play and put them in their hand or graveyard.
• Users can click on cards in their graveyard and put them in their hand or into play.
• Users can click their decks to draw.

Most interactions in envoy will be between logged in users, so we need an easy way for the integration tests to log in.

Currently, when we instrument our codebase for coverage with istanbul, we modify our source code. This is bad. It's even worse when the tests fail and bail partway through the suite and leave our codebase in an unstable state. We should build, instrument, and pass off our code to meteor in a scratch space.

In fed7dc7, we added jshint. It has never (in my experience) complained about code correctness/style. We should make add a .jshintrc file to make sure that jshint is configured well.

Users should be able to read all of the game state from the gameplay ui. This information includes:

• Cards in user's hand.
• Number of cards in opponent's hand.
• Cards in play.
• Cards in graveyards.
• Number of cards in each deck.
• Each player's life total.
• Each player's energy.

v0.1.0 introduced a lot of gameplay ui and functionality. It's extremely unsightly and we should change that for v0.2.0.

As a user, I would like to be able to create and configure a game with the deck (custom or prebuilt) of my choice. Once the game is created, it should be added to a queue of open games so that I can find an opponent. Other players should be able to join my game while I don't have an opponent.

From the README:

To run envoy locally, you must first globally install:

firefox
java
meteor
mongodb
xvfb

I would consider using docker to package your dependencies (either as one bigass container or multiple?) then using volume mounts to run stuff... its a lot lighter weight then vagrant and is much faster. I wrote a blog post about this http://lightsofapollo.github.io/2014/01/31/docker-volumes/

Sadly there are not too many options to deploy the docker containers outright (but the process is very similar to what heroku does to generate their LXC containers)

Setting up to develop with grunt build is really easy! However, the test suite also builds the app and both the development and test workflows make use of the /build directory. We should use two different directories to avoid development and test collisions. Also, we should run meteor and mongo on different ports during testing to avoid port collisions.

The project is starting to take shape as the codebase grows. I'm really enjoying being able to move fast because stuff works and I'm doing things my way. We should document what that is in the hopes that my process is good process!

The v0.1.0 release will introduce features that are worth showing non-engineers and having game players experiment with! That makes now a great time to come up with a janky way to unleash envoy upon the world.

• One idea is to use heroku (see https://github.com/oortcloud/heroku-buildpack-meteorite)
• Another is to use docker container hosting

We have [thus far] been too willy nilly about syncing all of our data to every client all the time. This has serious performance implications! We should take some time for v0.2.0 to make sure that we're only syncing that needs to be sent to each client.

In dbf6ddc we added a "build" task that decoupled our source tree from the actual running of our app. This was a good thing. However, it also means that meteor's nice live updates are no longer working. We should add a grunt task to rebuild envoy when the source tree changes.

At f1aca13 they include a rogue } character at the end of the deckname.

In c208c45 we added an incremental, as-you-save build task that watches the app directory for source code changes and copies them over to build. Sadly, this is quite slow. We should speed things up by doing something like polling the filesystem more frequently or only copying over files which have been changed instead of the whole source tree.

Meteor 0.8.0 is out with a faster templating engine called blaze. We should upgrade from 0.7. 2/spark.