[CLI Tool] Cadastro de Eventos about eventos HOT 26 CLOSED

Feito!

cc: @frontendbr/admins

from eventos.

@vitorbritto boa!

from eventos.

+1
@vitorbritto seria interessante visualizar os eventos também.

from eventos.

Eu ia comentar sobre termos um CLI lá na outra issue, mas achei que seria por muitos assuntos em pauta.

Eu acho a ideia bem interessante, quero ver isso de perto pra poder aprender e acho que poderíamos ter algo que nem o rinaldi fez pro hacker news link pra quem não viu

from eventos.

Gosto bastante da ideia de trabalharmos com o inquirer. Tenho alguns projetos baseado nele.

Cc: @frontendbr/admins

from eventos.

@lucasbsilva com certeza. Eu acredito que podemos começar com um MVP, fazendo o registro e utilizar o blessed para fazer o output dos eventos no terminal.

from eventos.

@leandrogrillo boa referência!

from eventos.

@vitorbritto concordo, temos que ir construindo aos poucos, um MVP seria o mais viável agora e com o tempo ir evoluindo a ferramenta.

Acho que a demanda de criarmos o evento pelo CLI é o MVP no caso e depois estudamos outras features pra ele.

Até acho que isso pode ser feito sem termos o site pronto.

from eventos.

@lendrogrillo acredito que sim. Vamos aguardar as considerações dos colegas para dar início ao projeto.

Summon: @frontendbr/admins

from eventos.

@vitorbritto demoro mano :) vamos ficar no aguardo :D

from eventos.

Top a ideia! Acho que a primeira coisa é definir a estrutura do JSON que vai ser gerado.

Como o site vai ser SPA, o ideal era ter um único JSON listando todos os eventos, pra fazer um único request dele. Então, essa CLI vai editar esse JSON e adicionar a nova entrada, correto?

Se tiver mais de um, vamos ter que, de alguma forma, listar todos os JSONs em algum lugar pra saber pra onde fazer o request, já que não rola filesystem no browser, e vamos acabar tendo dois trabalhos.

Não sei se vocês tem alguma ideia diferente disso. O que se passa nessas cabecinhas? xD

from eventos.

@fdaciuk na verdade eu pensei em termos um api rest. Acho que nesse caso por nao termos tanta informacao pesada, nao teria problemas em ter mais de uma resquest. Com o webservice daria pra cuidarmos do cache disso e etc, é só uma ideia.

from eventos.

@leandrogrillo entendi. É que a ideia inicial do projeto é ele ser um SPA, e ficar hospedado no GitHub pages. O problema de fazer backend disso vai ser a burocra que vai gerar pra manter servidor, vai ter que ter responsáveis pelo server, etc.

Se fizer só como SPA, manda um PR com a alteração no JSON e boa. A parada já tá no ar =)

from eventos.

Mas se fizermos com um servidor, permitimos que outros serviços possam se aproveitar dele. Numa ideia bem mais distante, o server pode se tornar um único hub de eventos, e de lá pegamos pelas "categorias" que desejamos.

Honestamente, vejo sendo tão trabalhoso como a CLI, mas com uma escalabilidade muito mais sustentável.

from eventos.

Ah sim, isso é certo. Mas eu acho que dá pra pensar nisso depois de ter ao menos uma versão do negócio rodando. Se ficar adicionando muita coisa agora, o negócio nem sai do lugar =)

Minha opinião: acho que a gente pode seguir na ideia do SPA com o CLI, e depois fazer as melhorias: criar uma API pra ser consumida por outros serviços, definir como vai ficar estrutura de server e talz.

Só acho que precisamos ter algo rodando primeiro, senão gera muita ideia e acaba que nada sai do papel.

from eventos.

Acho que é um ponto bem válido. Mas temos tantas mãos pra ajudar nesse projeto... será que não sai mesmo?

from eventos.

@fdaciuk foi o que o @vitorbritto falou, vamos partir pro MVP e depois vamos evoluindo, mas já fica a ideia parar partimos em segundo plano.

Só acho que tipo um CLI pra rodar local, só no repo não faria tanto sentido assim. Posso estar falando besteira, mas é o que eu acho.

from eventos.

Principalmente com um acompanhamento público do projeto. Acabo achando que fazer uma CLI é jogar um pouco de tempo de produção fora. Um serviço de backend desses fica pronto bem rápido, principalmente se usarem algo como o Loopback.

from eventos.

Tudo bem que esse tipo de framework é super opinado, mas para o que queremos fazer é mais do que o suficiente.

from eventos.

@leandrogrillo @fernandofleury vejo num primeiro momento um CLI Tool simplificado, funcional e que consigamos cadastrar os eventos na organização. Concordo sobre a API e em termos um server-side para escalar melhor, mas podemos fazer de forma granular.

Então, essa CLI vai editar esse JSON e adicionar a nova entrada, correto?

Pensei nisso @fdaciuk. =]

from eventos.

@leandrogrillo @fernandofleury @fdaciuk exatamente a ideia de editar um JSON inicialmente. Depois eu concordo plenamente com o @fernandofleury de ter um backend API pra isso. Agora, editar o JSON já resolve pra gente :)

O que pensei tbm, é integrar uma ferramenta de formulário (Google Docs, Typeform, etc.) com a ferramenta de CLI. Assim, quem não manja muito de abrir PR e etc. poderia contribuir também. Apesar do público ser dev, tem gente que não manja muito de Github. E mais ainda, teríamos uma forma de validar os dados antes de chegarem na ferramenta.

from eventos.

+1

from eventos.

Eae galera, vamos tocar o projetin, começar a por algo no papel pra termos algo mais palpável?

from eventos.

Estou com 3 projetos para liberar. Está corrido por aqui. Posso
organizar algo no final de semana e repasso aqui. =]

On 25/02/16 10:18, Leandro Grillo wrote:

Eae galera, vamos tocar o projetin, começar a por algo no papel pra
termos algo mais palpável?

—
Reply to this email directly or view it on GitHub
#10 (comment).

from eventos.

De boas @vitorbritto mandei algo aqui só pra mantermos a ideia viva e não ficar só por aqui!

A ideia era termos sugestões de estruturas e afins, achar a melhor forma. Se a galera quiser sugerir algo, ex de como a estrutura de como vai ser o JSON, posta ae para discutirmos

from eventos.

@leandrogrillo @vitorbritto digo o mesmo que o Vitor. Semaninha foi tensa. Na próxima já consigo ajudar de boas. Seria legal marcar um hangout, como fizemos no de Eventos hein

from eventos.