search

PokemonGoers / Catch-em-all

Now that we have tons of data about Pokemon (what they are, where they are, what’s their relationship, what they can transform into, which attacks they can perform, aso) we want to integrate it all into a comprehensive website. This website should contain sections about each Pokemon and its details. Additionally, the website should register the user’s location and tell the user how close is that the predicted pokemon to him/her. Additionally you will be incorporating the apps that were created by project B,C and D into the website. Your group will need to create automated builds and testing for this apps and use continuous integration to pull in new changes in the code repositories. Apps from projects B-D should be packaged and made available on NPM. Ideally when you completed these tasks the webapp component would integrate the apps by “requiring’ them. Here is a possible user story: when a user opens the website or the app the current location of the user will be shown. Additionally, the website/app will show automatically where the pokemons that are currently active are and where the pokemons that we predict to active in the nearest future (i.e. within half a day) will be located (all of this will be available from the app developed in project D). Hopefully, the website will be somewhat crowded by that data. Then, there needs to be a menu bar or something available (e.g. above the map or on the right side to it) that will list currently active or predicted pokemons. Clicking on one of them will make other pokemons on the map disappear, except of this clicked one. Separate web pages would allow the search and presentation of individual Pokemons and the information we gathered about them, including third party data (project A) and twitter analysis (project C)
9 stars 7 forks source link

Add CI, refactor code to ES2016 style #18

Closed MajorBreakfast closed 8 years ago

MajorBreakfast commented 8 years ago
MajorBreakfast commented 8 years ago

Don't merge just yet. There seems to be a problem with the test glob pattern. Resolving now...

MajorBreakfast commented 8 years ago

Ok done

@WoH I yield to thee the code review honours once more

@philbu I refactored your code. Plz have also a look at lib/main (formerly server.js)

WoH commented 8 years ago

Looks good to me, can only comment Mocha / Chai though.

philbu commented 8 years ago

Everything seems fine to me. Should I click on this big green "Merge pull request" button or is there a voting system or sth like that? (Don't hit me please, I am not used to github and its processes ;) )

MajorBreakfast commented 8 years ago

@philbu You withstood tempation of clicking the button :) That's good. I'd say that generally it's best to merge PRs fast, but not too fast either because more eyes are always better.

BTW since it seems that you're new to PRs:

sacdallago commented 8 years ago

@philbu and I'll only add: Unfortunately there's no consensus in GitHub, but I would do it like this:

  1. If everything is really fine, you can merge it.
  2. If you are unsure you definetly might have a reason, so comment the code or comment the PR, or let someone know that "I have read the PR but .." and invite other reviewers.
  3. If you see that this should not be merged at all, then immediately reject it. There's no point in keepeing useless PRs open! And as long as you close them without deleting the branch, nothing is really gone (even after deleting the branch, you could potentially still recover it :) ). So no worries!

@MajorBreakfast Yes, PRs should extinguish between 2-3 days. If it takes many commits / much time to fix a PR, close it and then open it again once all the fixes have all been implemented and it's ready to be reviewed again.

also: you forgot to assign people here -->

Assigning people to a PR is important because you can keep track of who read it. Also it's ok to assign only one other team member to a PR, it will then be his/her responsibility to judge if another reviewer is needed or not (like the points above).

Last but not least for @PokemonGoers/catch-em-all at the end of a PR delete the branch! It's not mean, it's just that trust me! :) If someone is still working on a branch even if the PR is in review, he/she didn't understand the use of branches in the GitFlow model :) But this way, they will learn :joy:

Also: You can mention your entire team by using the @ that I just used above :D