gdgtoledo / linneo Goto Github PK

Veo que nuestro stack necesita unos minimos

• Go v1.10.0+
• Docker-compose v18.06.0+

por ejemplo al hacer make build sin satisfacer la versión para tener el compose file format

docker-compose -f ./docker/docker-compose.yml build
ERROR: Version in "././docker/docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g "2.2" or "3.3") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/
make: *** [Makefile:3: build] Error 1

Añadir estos minimos en la documentación del proyecto

La idea es poder definir un template de PR, de modo que ayuden a los revisores a entender el contexto y las consideraciones realizadas a la hora de enviar una PR.

Entidades del Dominio

Un primer posible enfoque podría ser éste, en el que se tiene una única entidad Tree:

tree:
  name: string
  geo:
    lat: float
    long: float

El name por defecto sería a almez, porque si lo dejamos así sería extensible a cualquier otro tipo de árbol.
En cuanto a la geolocalización, con almacenar las coordenadas sería suficiente para abstraerlo del sistema de representación (Google Maps, Open Street Map...)

Originally posted by @mdelapenya in #1 (comment)

Umm según lo que comentas debajo, estaría bien colocar un type: String em eñ struc

Este endpoint almacenará una nueva planta en el almacenamiento primario, en este caso Elasticsearch

Posiblemente haya que nombrarla pull_request_template.md

Este endpoint borrará una planta en el almacenamiento primario, en este caso Elasticsearch, identificada por su clave primaria, o id.

Una respuesta con éxito DEBERÍA ser un 200 (Accepted) si el recurso ha sido encolado para su borrado (operación asíncrona), o 200 (OK) / 204 (No Content) si el recurso ha sido borrado permanentemente (operación síncrona).

Cosas a incluir:

• Reglas de estilo
• Número de OKs para mergear
• Formato de las PRs
  ...

Enlazar este documento con el readme.md principal en una sección que se llame

¿Cómo puedo contribuir?

Para contribuir tenemos un documento con información detallada de todo el contexto que necesitas para aportar valor al proyecto.

Discutamos aquí sobre:

• APIs
• Lenguaje
• Entidades del dominio
• Tipos de tests
• Casos de uso
• etc.

Una de las ventajas de usar el Elastic Stack es que tiene APM Out-of-the-box.

https://www.elastic.co/guide/en/apm/agent/go/current/instrumenting-source.html#builtin-modules-apmgin

Queremos automatizar todo lo posible las tareas que eliminen productividad

• checks de formateo de código
• Comprobar el correcto nombrado de commits
• Lanzar los test locales

https://pre-commit.com permite hacerlo

Casos de Uso

• Como ciudadano, quiero ver todos los árboles del tipo almez en un mapa
• Como administrador, quiero dar de alta un árbol del tipo almez a partir de su ubicación
• Como administrador, quiero dar de baja un árbol del tipo almez a partir de su ubicación

Originally posted by @mdelapenya in #1 (comment)

Implementación de los casos de uso

Vamos a crear un API REST con los siguientes métodos:

1. HTTP GET/plants, que retornará todas las plantas almacenadas (Ver #5)
2. HTTP POST/plants, que almacenará una nueva planta (Ver #6)
3. HTTP DELETE/plants/{id}, que eliminará una planta por su id (Ver #7)

Cada método tendrá su propio issue

Pues esto.

¿Necesitamos HTTP2?
¿Nos sale gratis?
De ser no, ¿Cuanto nos costaria?

Este endpoint retornará todas las plantas existentes en el almacenamiento primario, en este caso Elasticsearch

Este endpoint recogerá una planta del almacenamiento primario, en este caso Elasticsearch, identificada por su clave primaria, o id.

Una respuesta con éxito DEBERÍA ser 200 (OK) / 204 (No Content) si el recurso ha sido recogido para su devolución al cliente que hizo la petición (operación síncrona).