rmsouza · March 3, 2023 17:43 · Jul 5, 2019 · Jul 5, 2019 · Jul 5, 2019 · Jul 5, 2019
diff --git a/README.md b/README.md
@@ -98,7 +98,7 @@ Exemplo:
 
 # Requisitos
 
-1. Use a linguagem Javascript, no backend utilize a plataforma do NodeJS, no frontend utilize React JS e banco de dados MongoDB.
+1. Use a linguagem Javascript, no backend utilize a plataforma do NodeJS, no frontend utilize React JS. Como banco de dados utilize MongoDB.
 2. Faça testes unitários, suite de testes bem organizados.
 3. Use git e tente fazer commits pequenos e bem descritos.
 4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código.

diff --git a/README.md b/README.md
@@ -46,7 +46,7 @@ Crie uma API RESTful simples com apenas um endpoint que retorne uma lista com os
 
 ## Task 4
 
-Crie uma interface React JS simples que consuma essa informação e apresente na tela um relatório de cada jogo (simplesmente imprimindo o hash) e um ranking geral de kills por jogador em formato de lista, tabela ou o que achar mais adequado. 
+Crie uma interface React JS simples que consuma essa informação e apresente na tela um relatório de cada jogo e um ranking geral de kills por jogador em formato de lista, tabela ou o que achar mais adequado. 
 
 Causas de morte (retirado do [código fonte](https://github.com/id-Software/Quake-III-Arena/blob/master/code/game/bg_public.h))
 

diff --git a/README.md b/README.md
@@ -42,7 +42,7 @@ Após construir o parser, salve as informações no MongoDB. Fique a vontade pra
 
 ## Task 3
 
-Crie uma API simples com apenas um endpoint que retorne uma lista com os resultados vindos do Banco de Dados.
+Crie uma API RESTful simples com apenas um endpoint que retorne uma lista com os resultados vindos do Banco de Dados.
 
 ## Task 4
 

diff --git a/README.md b/README.md
@@ -38,7 +38,7 @@ Para cada jogo o parser deve gerar algo como:
 
 ## Task 2
 
-Após construi o parser, salve as informações no MongoDB. Fique a vontade pra construi o modelo de dados que achar mais adequado.
+Após construir o parser, salve as informações no MongoDB. Fique a vontade pra construir o modelo de dados que achar mais adequado.
 
 ## Task 3
 

diff --git a/README.md b/README.md
@@ -2,7 +2,7 @@
 
 ## Task 1
 
-Construa um parser para o arquivo de log games.log.
+Construa um parser para o arquivo de log games.log utilizando Node.js.
 
 O arquivo games.log é gerado pelo servidor de quake 3 arena. Ele registra todas as informações dos jogos, quando um jogo começa, quando termina, quem matou quem, quem morreu pq caiu no vazio, quem morreu machucado, entre outros.
 
@@ -38,11 +38,15 @@ Para cada jogo o parser deve gerar algo como:
 
 ## Task 2
 
-Após construir o parser construa um script que imprima um relatório de cada jogo (simplemente imprimindo o hash) e um ranking geral de kills por jogador.
+Após construi o parser, salve as informações no MongoDB. Fique a vontade pra construi o modelo de dados que achar mais adequado.
 
-## Plus
+## Task 3
 
-Gerar um relatório de mortes agrupando pelo motivo da morte, por partida.
+Crie uma API simples com apenas um endpoint que retorne uma lista com os resultados vindos do Banco de Dados.
+
+## Task 4
+
+Crie uma interface React JS simples que consuma essa informação e apresente na tela um relatório de cada jogo (simplesmente imprimindo o hash) e um ranking geral de kills por jogador em formato de lista, tabela ou o que achar mais adequado. 
 
 Causas de morte (retirado do [código fonte](https://github.com/id-Software/Quake-III-Arena/blob/master/code/game/bg_public.h))
 
@@ -94,10 +98,10 @@ Exemplo:
 
 # Requisitos
 
-1. Use a linguagem Javascript, no backend utilize a plataforma do NodeJS e no frontend utilize AngularJS 1.
+1. Use a linguagem Javascript, no backend utilize a plataforma do NodeJS, no frontend utilize React JS e banco de dados MongoDB.
 2. Faça testes unitários, suite de testes bem organizados.
 3. Use git e tente fazer commits pequenos e bem descritos.
-4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código
+4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código.
 5. Siga o que considera boas práticas de programação, coisas que um bom desenvolvedor olhe no seu código e não ache "feio" ou "ruim".
 6. Após concluir o teste faça um zip e mande anexado no email de contato ou envie o link do repositório do github.
 

diff --git a/README.md b/README.md
@@ -94,11 +94,11 @@ Exemplo:
 
 # Requisitos
 
-1. Use a linguagem que você tem mais habilidade (dentro das linguagens que priorizamos na empresa, obviamente começando com Ruby, depois Javascript, se tiver Java - pois fazemos Android, talvez Objective-C/Swift (se for iOS).
+1. Use a linguagem Javascript, no backend utilize a plataforma do NodeJS e no frontend utilize AngularJS 1.
 2. Faça testes unitários, suite de testes bem organizados.
 3. Use git e tente fazer commits pequenos e bem descritos.
 4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código
 5. Siga o que considera boas práticas de programação, coisas que um bom desenvolvedor olhe no seu código e não ache "feio" ou "ruim".
-6. Após concluir o teste faça um zip e mande anexado no email de contato
+6. Após concluir o teste faça um zip e mande anexado no email de contato ou envie o link do repositório do github.
 
 HAVE FUN :)
diff --git a/README.md b/README.md
@@ -94,9 +94,9 @@ Exemplo:
 
 # Requisitos
 
-1. Use a linguagem que você tem mais habilidade.
-2. Faça testes unitários.
-3. Use git e tente fazer commits pequenos.
+1. Use a linguagem que você tem mais habilidade (dentro das linguagens que priorizamos na empresa, obviamente começando com Ruby, depois Javascript, se tiver Java - pois fazemos Android, talvez Objective-C/Swift (se for iOS).
+2. Faça testes unitários, suite de testes bem organizados.
+3. Use git e tente fazer commits pequenos e bem descritos.
 4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código
 5. Siga o que considera boas práticas de programação, coisas que um bom desenvolvedor olhe no seu código e não ache "feio" ou "ruim".
 6. Após concluir o teste faça um zip e mande anexado no email de contato

diff --git a/README.md b/README.md
@@ -97,6 +97,8 @@ Exemplo:
 1. Use a linguagem que você tem mais habilidade.
 2. Faça testes unitários.
 3. Use git e tente fazer commits pequenos.
-4. Após concluir o teste suba o código para um repositório privado no Bitbucket e nos dê permissão de leitura.
+4. Faça pelo menos um README explicando como fazer o setup, uma explicação da solução proposta, o mínimo de documentação para outro desenvolvedor entender seu código
+5. Siga o que considera boas práticas de programação, coisas que um bom desenvolvedor olhe no seu código e não ache "feio" ou "ruim".
+6. Após concluir o teste faça um zip e mande anexado no email de contato
 
 HAVE FUN :)
diff --git a/README.md b/README.md
@@ -32,9 +32,9 @@ Para cada jogo o parser deve gerar algo como:
 
 ### Observações
 
-1. Quando o `\<world\>` mata o player ele perde -1 kill.
-2. `\<world\>` não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
-3. `total_kills` são os kills dos games, isso inclui mortes do `\<world\>`.
+1. Quando o `<world>` mata o player ele perde -1 kill.
+2. `<world>` não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
+3. `total_kills` são os kills dos games, isso inclui mortes do `<world>`.
 
 ## Task 2
 

diff --git a/README.md b/README.md
@@ -32,9 +32,9 @@ Para cada jogo o parser deve gerar algo como:
 
 ### Observações
 
-1. Quando o "\<world\>" mata o player ele perde -1 kill.
-2. "\<world\>" não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
-3. `total_kills` são os kills dos games, isso inclui mortes do "<world>".
+1. Quando o `\<world\>` mata o player ele perde -1 kill.
+2. `\<world\>` não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
+3. `total_kills` são os kills dos games, isso inclui mortes do `\<world\>`.
 
 ## Task 2
 

diff --git a/README.md b/README.md
@@ -34,6 +34,7 @@ Para cada jogo o parser deve gerar algo como:
 
 1. Quando o "\<world\>" mata o player ele perde -1 kill.
 2. "\<world\>" não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
+3. `total_kills` são os kills dos games, isso inclui mortes do "<world>".
 
 ## Task 2
 

diff --git a/README.md b/README.md
@@ -93,9 +93,9 @@ Exemplo:
 
 # Requisitos
 
-1. Use ruby.
+1. Use a linguagem que você tem mais habilidade.
 2. Faça testes unitários.
 3. Use git e tente fazer commits pequenos.
-4. Após concluir o teste suba o código para o github e nos envie a url do repositório.
+4. Após concluir o teste suba o código para um repositório privado no Bitbucket e nos dê permissão de leitura.
 
 HAVE FUN :)
diff --git a/README.md b/README.md
@@ -39,6 +39,58 @@ Para cada jogo o parser deve gerar algo como:
 
 Após construir o parser construa um script que imprima um relatório de cada jogo (simplemente imprimindo o hash) e um ranking geral de kills por jogador.
 
+## Plus
+
+Gerar um relatório de mortes agrupando pelo motivo da morte, por partida.
+
+Causas de morte (retirado do [código fonte](https://github.com/id-Software/Quake-III-Arena/blob/master/code/game/bg_public.h))
+
+	// means of death
+	typedef enum {
+		MOD_UNKNOWN,
+		MOD_SHOTGUN,
+		MOD_GAUNTLET,
+		MOD_MACHINEGUN,
+		MOD_GRENADE,
+		MOD_GRENADE_SPLASH,
+		MOD_ROCKET,
+		MOD_ROCKET_SPLASH,
+		MOD_PLASMA,
+		MOD_PLASMA_SPLASH,
+		MOD_RAILGUN,
+		MOD_LIGHTNING,
+		MOD_BFG,
+		MOD_BFG_SPLASH,
+		MOD_WATER,
+		MOD_SLIME,
+		MOD_LAVA,
+		MOD_CRUSH,
+		MOD_TELEFRAG,
+		MOD_FALLING,
+		MOD_SUICIDE,
+		MOD_TARGET_LASER,
+		MOD_TRIGGER_HURT,
+	#ifdef MISSIONPACK
+		MOD_NAIL,
+		MOD_CHAINGUN,
+		MOD_PROXIMITY_MINE,
+		MOD_KAMIKAZE,
+		MOD_JUICED,
+	#endif
+		MOD_GRAPPLE
+	} meansOfDeath_t;
+
+Exemplo:
+
+	"game-1": {
+		kills_by_means: {
+			"MOD_SHOTGUN": 10,
+			"MOD_RAILGUN": 2,
+			"MOD_GAUNTLET": 1,
+			"XXXX": N
+		}
+	}
+
 # Requisitos
 
 1. Use ruby.

diff --git a/README.md b/README.md
@@ -6,7 +6,7 @@ Construa um parser para o arquivo de log games.log.
 
 O arquivo games.log é gerado pelo servidor de quake 3 arena. Ele registra todas as informações dos jogos, quando um jogo começa, quando termina, quem matou quem, quem morreu pq caiu no vazio, quem morreu machucado, entre outros.
 
-O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em cada jogo deve coletar as informações de morte.
+O parser deve ser capaz de ler o arquivo, agrupar os dados de cada jogo, e em cada jogo deve coletar as informações de morte.
 
 ### Exemplo
 
@@ -16,7 +16,7 @@ O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em ca
 
   	2:22 Kill: 3 2 10: Isgalamido killed Dono da Bola by MOD_RAILGUN
 
-  O player "Isgalamido" marou o player Dono da Bola usando a arma Railgun.
+  O player "Isgalamido" matou o player Dono da Bola usando a arma Railgun.
 
 Para cada jogo o parser deve gerar algo como:
 

diff --git a/README.md b/README.md
@@ -10,11 +10,11 @@ O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em ca
 
 ### Exemplo
 
-  21:42 Kill: 1022 2 22: <world> killed Isgalamido by MOD_TRIGGER_HURT
+  	21:42 Kill: 1022 2 22: <world> killed Isgalamido by MOD_TRIGGER_HURT
 
   O player "Isgalamido" morreu pois estava ferido e caiu de uma altura que o matou.
 
-  2:22 Kill: 3 2 10: Isgalamido killed Dono da Bola by MOD_RAILGUN
+  	2:22 Kill: 3 2 10: Isgalamido killed Dono da Bola by MOD_RAILGUN
 
   O player "Isgalamido" marou o player Dono da Bola usando a arma Railgun.
 

diff --git a/gistfile1.txt → games.log b/gistfile1.txt → games.log
diff --git a/gistfile1.txt b/gistfile1.txt
diff --git a/README.md b/README.md
@@ -1,10 +1,14 @@
+# Quake log parser
+
+## Task 1
+
 Construa um parser para o arquivo de log games.log.
 
 O arquivo games.log é gerado pelo servidor de quake 3 arena. Ele registra todas as informações dos jogos, quando um jogo começa, quando termina, quem matou quem, quem morreu pq caiu no vazio, quem morreu machucado, entre outros.
 
 O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em cada jogo deve coletar as informações de morte.
 
-## Exemplo
+### Exemplo
 
   21:42 Kill: 1022 2 22: <world> killed Isgalamido by MOD_TRIGGER_HURT
 
@@ -16,21 +20,30 @@ O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em ca
 
 Para cada jogo o parser deve gerar algo como:
 
-  game: {
-    total_kills: 45;
-    players: { "Dono da bola", "Isgalamido", "Zeh", "..." }
-    kills: {
-      "Dono da bola": 5,
-      "Isgalamido": 18,
-      "Zeh": 20
-    }
-  }
-
+    game_1: {
+	    total_kills: 45;
+	    players: ["Dono da bola", "Isgalamido", "Zeh"]
+	    kills: {
+	      "Dono da bola": 5,
+	      "Isgalamido": 18,
+	      "Zeh": 20
+	    }
+	  }
 
+### Observações
 
+1. Quando o "\<world\>" mata o player ele perde -1 kill.
+2. "\<world\>" não é um player e não deve aparecer na lista de players e nem no dicionário de kills.
 
-  
+## Task 2
 
+Após construir o parser construa um script que imprima um relatório de cada jogo (simplemente imprimindo o hash) e um ranking geral de kills por jogador.
 
-
+# Requisitos
+
+1. Use ruby.
+2. Faça testes unitários.
+3. Use git e tente fazer commits pequenos.
+4. Após concluir o teste suba o código para o github e nos envie a url do repositório.
 
+HAVE FUN :)
diff --git a/README.md b/README.md
@@ -7,10 +7,26 @@ O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em ca
 ## Exemplo
 
   21:42 Kill: 1022 2 22: <world> killed Isgalamido by MOD_TRIGGER_HURT
+
   O player "Isgalamido" morreu pois estava ferido e caiu de uma altura que o matou.
 
   2:22 Kill: 3 2 10: Isgalamido killed Dono da Bola by MOD_RAILGUN
+
   O player "Isgalamido" marou o player Dono da Bola usando a arma Railgun.
+
+Para cada jogo o parser deve gerar algo como:
+
+  game: {
+    total_kills: 45;
+    players: { "Dono da bola", "Isgalamido", "Zeh", "..." }
+    kills: {
+      "Dono da bola": 5,
+      "Isgalamido": 18,
+      "Zeh": 20
+    }
+  }
+
+
 
 
 

diff --git a/README.md b/README.md
@@ -0,0 +1,20 @@
+Construa um parser para o arquivo de log games.log.
+
+O arquivo games.log é gerado pelo servidor de quake 3 arena. Ele registra todas as informações dos jogos, quando um jogo começa, quando termina, quem matou quem, quem morreu pq caiu no vazio, quem morreu machucado, entre outros.
+
+O parser deve ser capaz de ler o arquivo, agrugar os dados de cada jogo, e em cada jogo deve coletar as informações de morte.
+
+## Exemplo
+
+  21:42 Kill: 1022 2 22: <world> killed Isgalamido by MOD_TRIGGER_HURT
+  O player "Isgalamido" morreu pois estava ferido e caiu de uma altura que o matou.
+
+  2:22 Kill: 3 2 10: Isgalamido killed Dono da Bola by MOD_RAILGUN
+  O player "Isgalamido" marou o player Dono da Bola usando a arma Railgun.
+
+
+
+
+
+
+