Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gerador de páginas #59

Open
rafaell-lycan opened this issue May 29, 2014 · 26 comments
Open

Gerador de páginas #59

rafaell-lycan opened this issue May 29, 2014 · 26 comments

Comments

@rafaell-lycan
Copy link

Pessoas legais, tudo bem?

Estou ultimamente brincando com Jekyll no meu blog e estou curtindo.

Vantagens: Fácil de aprender, suporte a Markdown, ridiculo para implementar coisinhas.

Desvantagens: Pra desenvolver localmente, é necessário ter Ruby instalado.

Seria legal dar uma repaginada, onde listamos todos os eventos (home) gerando novas páginas com detalhes sobre cada evento. Assim fica tudo mais organizado e ainda escrevemos um único arquivo (.md) sobre cada novo evento.

Outras sugestões são bem vindas.

@rafaell-lycan
Copy link
Author

Outra coisa, isso pode resolver o problema de performance por conta de ter N mapas na home page.

No celular fica meio pesado (to fazendo a parte responsiva =] )

@williamespindola
Copy link
Member

O @IAMFELIPESOUZA tinha algumas idéias também podemos colocar todas em prática.
Eu cheguei a pensar no jekyll um tempo atras, por conta do markdown, desisti porque queria fazer alguns filtros automáticos de acordo com a geolocalização de uma olhada no branch develop. Então acabei desistindo, e trabalhando com javascript.

@rafaell-lycan
Copy link
Author

legal @williamespindola , podemos analisar N condições e matar todas numa versão nova.

Outra coisa, podemos também pegar um dominio .io só fazendo um alias pra URL do github.

@williamespindola
Copy link
Member

@rafaell-lycan ja esta em um domínio .io http://saiadecasa.github.io/

@rogeriopradoj
Copy link
Member

We are poor :-(!

@rogeriopradoj
Copy link
Member

@humrochagf
Copy link

Vocês não acham legal usar angular não?

  • É uma tecnologia fácil de aprender
  • É algo que está sendo bastante usado no mercado, então o conhecimento pode ser aproveitado
  • Por enquanto dá para colocar os eventos em um arquivo javascript para funcionar como model
  • E se vocês quiserem, futuramente, colocar um backend para usar banco de dados e tals a refatoração é mínima

@rogeriopradoj
Copy link
Member

Cara, manda um PR com sua ideia funcionando, blz?

Achei muito interessante!

Falou!


Rogerio

@humrochagf
Copy link

Tranquilo, vou montar a estrutura aqui e mando

@rafaell-lycan
Copy link
Author

To montando o website com Jekyll.

Uma dúvida, vai permanecer o mesmo layout?

Angular também é legal, porque se não quisermos usar DB, podemos alimentar um JSON como recurso e configurar para mostrar apenas eventos que ainda não aconteceram a partir de Date.now()

Qual a melhor solução? =)

@rafaell-lycan
Copy link
Author

Outra coisa, com Jekyll cada evento é um arquivo.md, isso acho bem válido pra postar novos eventos.

@rogeriopradoj
Copy link
Member

rogeriopradoj commented Feb 27, 2015 via email

@williamespindola
Copy link
Member

Sim pessoal nos envie protótipos! Temos um no develop em produção também...
A única coisa que pedimos é que a inclusão e exclusão do evento seja de forma simples e via PR ;)

@iamfelipemattos
Copy link
Member

@williamespindola seria possível o proprio usuário cadastrar o evento no site e automaticamente isso bate no endpoint do github remetendo a um PR do mesmo na org?

@rogeriopradoj
Copy link
Member

Esse não é o foco agora.

O foco agora é manter apenas com os Pull Requests mesmo, sem inclusão pelo próprio site.

A nossa idéia sempre foi "forçar" esse fluxo do Git e Github para os contribuidores, dessa forma o pessoal aprende o processo para usar com qualquer projeto open source, entende?


Rogerio

On Sat, Feb 28, 2015 at 11:48 AM, Felipe Souza [email protected]
wrote:

@williamespindola seria possível o proprio usuário cadastrar o evento no site e automaticamente isso bate no endpoint do github remetendo a um PR do mesmo na org?

Reply to this email directly or view it on GitHub:
#59 (comment)

@iamfelipemattos
Copy link
Member

entendo @rogeriopradoj, eu só queria saber mesmo se é possível para quem sabe um uso futuro tanto nesse projeto como em outros por aí.

@abbondanza
Copy link

Ola pessoal, ainda estao discutindo o que vao usar para gerar paginas? Vi seu projeto e queria saber se posso ajudar..

@jackmakiyama
Copy link
Contributor

Daria pra fazer algo em js pra consumir um json, já que é bem básico o que tem nas páginas...

@abbondanza
Copy link

Isto que estava pensando, podem usar hogan.js (pq e leve) para gerar o HTML.

@jackmakiyama
Copy link
Contributor

A tecnologia eu não conheço pra apontar, mas qualquer uma que seja capaz de parsear um json e fazer um bind em um loop, atende o que precisaria aqui.

@danguilherme
Copy link
Contributor

Nada definido ainda? Acho que geradores estáticos (Jekyll, DocPad) são melhores, porque o site já vai pronto pro cliente, podendo usar um arquivo JSON externo pra manter os eventos do mesmo jeito.
Eu indico o DocPad por ser JavaScript, no Node.js, mas Jekyll também é bom.

@danguilherme
Copy link
Contributor

Fala pessoal;

Tenho uma sugestão para fazer sobre o site. Não sei se essa issue é o melhor lugar, mas antes de criar uma específica para isso gostaria de compartilhar a ideia.

A ideia é ter o mapa como principal item na tela. Dele ser o cara que o usuário vai ver. A página seria composta basicamente pelo mapa, que teria um marker pra cada evento. Já vi em vários lugares isso, mas o único exemplo que consigo lembrar agora é do Android Device Manager:

android-device-manager

Acho isso interessante porque a principal informação que o site quer passar é quando e onde os eventos vão acontecer, de maneira simples e direta - e é exatamente isso que o mapa vai fornecer. Poderia ter uma lista do lado com informações básicas de todos os eventos disponíveis no mapa e, clicando nesse evento (ou no marker dele), ele é centralizado no mapa e são mostrados seus detalhes.

Podemos usar também o recurso de junção de markers do Google Maps, caso os eventos sejam muito próximos:

markers-1
markers-2

Acho que isso traria uma informação mais concentrada -- um mapa para todos os eventos ao invés de uma lista com diversos mapas --, mais fácil de navegar quando a lista de eventos for grande, além de economizar banda de internet e processamento, exatamente pelo fato de apenas um Google Maps estar sendo carregado.

@rogeriopradoj
Copy link
Member

@danguilherme olá, parece bem interessante essa proposta! (desculpe a demora para dar alguma posição!)

Será que você consegue dar ajuda junto com o #210 que o @LeoPersan está tocando?

Falou

Rogério

C/C @saiadecasa/collaborators @saiadecasa/owners

@danguilherme
Copy link
Contributor

@rogeriopradoj, obrigado pela resposta! Comecei implementando um exemplo: http://eventos-br.surge.sh/ (favor não reparar no estilo! hahaha). Como dito, o principal são os eventos, com um único mapa, e uma lista deles. Clicando tanto nos eventos quanto nos pins, os detalhes do evento são mostrados. O projeto está no GitHub e testei apenas no Chrome, enquanto fazia. Usei DocPad como gerador do site estático e um pouco de ES6, espero que dê pra entender tudo, mas qualquer coisa estou à disposição.

Caso seja essa solução a ser utilizada, precisaríamos de um layout meio que definido, infelizmente esse não é o meu forte rs.


Outra coisa, você comentou sobre a issue #210... é pra priorizar ela e depois implementar esse novo layout ou fazer os dois já integrados? De qualquer maneira, vou ver se consigo dar uma olhada nela.

@raymonsanches
Copy link
Contributor

Se eu puder emitir uma opinião é de que seria melhor usar o Jekyll, primeiro porque o Github dá suporte pras builds automáticas, não precisaria colocar em um dominio ou ter uma estrutura propria.

Segundo lugar, todos os eventos ficam em .md separados, o que facilita múltiplos PR's ao mesmo tempo, ou remover um evento por exemplo, não correndo o risco de um cagar no outro.

A gente usa Jekyll lá no DNE e roda muito bem. Nós temos uma estrutura própria de servidor, mas por outros motivos, mas tudo é gerado via Jekyll.

@rogeriopradoj
Copy link
Member

@raymonsanches acho que pode ser (ou não ser, hehe) qualquer gerador de estático. No meu blog estou usando o @sculpin que é em PHP. Lá no escritório usando o Hugo que é em Go. Entre os dois estou indo mais para o Hugo.

Na vantagem do build automático do Jekyll não tem muita dificuldade pois podemos colocar esse um script simples no Travis-CI por exemplo que gere os arquivos automaticamente.

Sobre os .md separados, acho que talvez possa sim virar uma opção, como o @rafaell-lycan já cobra a gente faz tempo ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants