Versionar o docker-compose.yml pode ser problemático. Cada ambiente tem suas peculiaridades e quando uma configuração de ambiente é sincronizada entre dispositivos podem acontecer conflitos de portas ou outras diretivas.

O Docker Compose prevê isso (https://docs.docker.com/compose/extends/#example-use-case) e nos dá até a opção de usar o docker-compose.override.yml. Então temos algumas opções à seguir:

Como foi convencionado há pouco tempo os nomes das tabelas/Entities e colunas/propriedades devem ser todas em inglês VEJA MAIS DETALHES.

Entity, Repository e Migration

A Entity deve ser alterada para User com as propriedades:

• id;
• name: nome legível do usuário;
• email: e-mail para autenticação e envio de mensagens;
• password: senha de acesso do usuário criptografada;
• roles: campo de texto que representará o grupo de usuário ou papéis do usuário no sistema. Possíveis valores: ROLE_ADMIN, ROLE_MODERADOR, ROLE_REDATOR e ROLE_MEMBRO
• avatar: (OPCIONAL) campo para o nome da imagem que representa o avatar do usuário;
• token: (OPCIONAL) campo que representa o token para recuperação de senha;
• session_name: (OPCIONAL) campo que representa o hash de sessão do usuário autenticado;
• status: campo booleano que representa o status do usuário;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• deleted_at: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• deleted_by: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Criação do Layout para o site da comunidade. Ficou firmado que um contato do @Junior-Shyko ficaria responsável pelo desenvolvimento.

As especificações/briefing do site podem ser vistas na issue #2 .

Não vale todo commit ser na branch master né?! :)
Que tal usar a abordagem do git-flow para tratar do versionamento semântico do projeto? Já que será uma obra feita a varias mãos. Acredito que seja uma boa abordagem. Vê esse [link aqui] para ver a doc em pt-BR.

Se sinta à vontade pra dá uma buscada no Youtube. E pra quem tem assinatura na School of Net esse mini curso também é da hora!

@dersonsena no Symfony 4 não é mais recomendado organizar sua lógica de negócios usando bundles. A separação agora é recomendada ser feita usando namespaces. Inclusive, no começo dessa doc sobre bundles fala isto. Essa abordagem do Symfony foi com o intuito de simplificar as coisas, dissociar mais o código do framework e substituir alguns conceitos do Symfony pelos recursos padrão do PHP, no Symfony 4.1 foi descontinuada a notação bundle em favor da notação regular do namespace do PHP.

The Bundle System

Nas versões do Symfony anteriores a 4.0, foi recomendado organizar seu próprio código de aplicativo usando pacotes configuráveis. Isso não é mais recomendado e os pacotes só devem ser usados ​​para compartilhar códigos e recursos entre vários aplicativos.

Um pacote é semelhante a um plugin em outro software, mas ainda melhor. Os principais recursos do framework Symfony são implementados com bundles (FrameworkBundle, SecurityBundle, DebugBundle, etc.). Eles também são usados para adicionar novos recursos em seu aplicativo por meio de bundles de terceiros.

Leia mais

Então, acredito que a gente deve rever essa abordagem.

Nesses dois links a seguir, Fabien o criador do Symfony também fala à respeito.

• http://fabien.potencier.org/symfony4-best-practices.html
• http://fabien.potencier.org/symfony4-monolith-vs-micro.html

Outro link útil -> https://symfony.com/blog/new-in-symfony-4-1-deprecated-the-bundle-notation

Definição

Implementação de uma tela para servir como configurações gerais do site e das áreas administrativas e área de membros. Inserir um item de navegação para a tela de configurações.

Entity, Repository e Migration

Deve-se ser criada a Entity Setting, seu Repository e Migration com as propriedades:

• id;
• code: código único para a configuração. Esse campo deve ser ÚNICO.
• title: título para a configuração;
• description: (OPCIONAL) uma descrição mais detalhada da configuração;
• value: valor da configuração. Esse campo deve poder receber valores de tamanho longo;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• updated_at: campo de data/hora que representa a data e hora da última atualização do registro;
• updated_by: ID do usuário que fez a ultima atualização do registro.

Fixture

Deverá ser criado uma Fixture com as informações abaixo:

code	title	description	value	created_at	updated_at	updated_by
FACEBOOK_URL	URL da fanpage da comunidade.	NULL	https://www.facebook.com/RAPADURAdoPoder	NOW()	NOW()	ID_DO_ADMIN
TWITTER_URL	URL da perfil do twitter da comunidade	NULL	https://twitter.com/phpcomrapadura	NOW()	NOW()	ID_DO_ADMIN
FLICKR_URL	URL da perfil do Flickr da comunidade	NULL	https://www.flickr.com/people/phpcomrapadura	NOW()	NOW()	ID_DO_ADMIN
GITHUB_URL	URL do Github da comunidade	NULL	https://github.com/PHPcomRapadura	NOW()	NOW()	ID_DO_ADMIN
POSTAGEM_BLOG_ATIVA	Liberar a criação de POST's na área des membros	NULL	1	NOW()	NOW()	ID_DO_ADMIN
POSTAGEM_VAGAS_ATIVA	Liberar a criação de vagas de emprego na área de membros.	NULL	1	NOW()	NOW()	ID_DO_ADMIN

Criação do Diagrama de entidades e relacionamentos das tabelas que já estão definidas até o momento. Os arquivos fontes do diagrama bem como as imagens exportadas, deverão ficar dentro do diretório /docs/der.

@marcialwushu ficará responsável por essa task e qualquer dúvida vai colocando aqui nessa issue. ;)

Definição

Criar funcionalidades de Create, Read, Update e Delete dos vídeos do RapaduraTV.

Entity, Repository e Migration

Deve-se ser criada a Entity Video, seu Repository e Migration com as propriedades:

• id;
• title: um título para o vídeo;
• slug: string com o slug do título do vídeo;
• description: (OPCIONAL) breve descrição para o vídeo;
• incorporation_code: código de incorporação do vídeo (Youtube, Vimeo e etc);
• status: campo booleano que representa o status do vídeo;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;

SITE PHPComRapadura

GERAL

• A ideia geral do site é que seja o cartão de visitas da comunidade, ou seja, um site institucional, de conteúdo para redes sociais e compartilhamentos e para nossos membros e internautas;
• Layout do site bem nordestino;
• Vocabulário e conteúdo também nordestino;
• Google Analytics;

PÁGINA INICIAL (HOME);

• Botões das redes sociais no topo do site: facebook, twitter, flikr, instragram e telegram;
• Banners (Carroussel) dos últimos eventos que a comunidade realizou;
• Banners/Artes listando os nossos tipos de eventos: PHPinga, Encontro de Dev's, Conference e etc;
• Últimos POSTS do blog;
• POSTS mais lidos do BLOG;
• Área para última vagas divulgadas pelos membros;
• RapaduraTV: vídeos realizados em prol da comunidade através do youtube;
• Área de patrocinadores/apoiadores da comunidade;
• Agenda dos eventos da comunidade;
• Área com as logomarcas de todas as comunidades PHP do Brasil;
• Rodapé:
  • Plugin do Facebook para Link na Fanpage da comunidade;
  • Plugin do twitter para ver os últimos tweets;
  • Botões das redes sociais;

BLOG:

• Blog convencional;

VAGAS DE TRABALHO:

• Espaço para listagem com consulta para as vagas de trabalho cadastradas pelos membros;

NOSSOS RETRATOS:

• Área para fotos dos eventos trazidas do Flickr;

CONTATO:

• Formulário convencional de contato com Captcha;

REGISTRE-SE:

• Área para o usuário se registrar e ficar apto a escrever um artigo no Blog passivo de aprovação;
• Campos: Nome Completo, Apelido, E-mail, Senha de Acesso com campo de confirmação de senha;
• Aplicar captcha;
• Validação de conta por e-mail;
• E-mail de boas vindas ao ativar a conta do usuário;

LOGIN:

• Área de Login para os membros do site;

ÁREA DO MEMBRO:

• Possibilidade de ver os artigos/posts criados;
• Ao criar um post, sistema deve enviar um e-mail para administração;
• Página para alteração da senha de acesso;
• Atualização de seus Dados Pessoais;

ADMINISTRATIVO:

• Área para administração do Conteúdo do Site (CMS);
• Área para administração dos POSTS dos membros (Aprovar, reprovar;
• Área para administração de POSTS;
• Área para administração de Membros;
• Área para administração dos Administradores/Moderadores;
• Área de configurações gerais do site/sistema;

Definição

Criar funcionalidades de Create, Read, Update e Delete da Agenda de eventos da comunidade.

Entity, Repository e Migration

Deve-se ser criada a Entity Eventos, seu Repository e Migration com as propriedades:

• id;
• date: data e hora do evento;
• title: um título para o vídeo;
• slug: string com o slug do título do vídeo;
• description: descrição completa do Evento;
• image: nome da imagem para servir como peça de divulgação;
• incorporation_code: (OPCIONAL) código de incorporação para integração de pagamentos como Sympla ou outros sites;
• status: campo booleano que representa o status do evento;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• deleted_at: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• deleted_by: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Então, o projeto está um pouco parado por conta da espera por um layout :( . Contudo, queremos dá continuidade as atividades que vinhamos desenvolvendo aqui com o objetivo de compartilhar principalmente conhecimento.

Para darmos continuidade decidimos pegar um template gratuito e usarmos. Para tanto precisamos antes de sugestões. Cole abaixo o links de temas que você acha interessante para ser usado no site da comunidade. Lembrando, eles devem ser gratuitos.

O link do tema que acumlar mais likes será o que nós usaremos para fazer o site da comunidade.

Fiquem à vontade quanto as sugestões, cole o link de quantas sugestões achar necessário.

Obrigado!

Definição

Criar funcionalidades de Create, Read, Update e Delete dos banners do site.

Entity, Repository e Migration

Deve-se ser criada a Entity Banner, seu Repository e Migration com as propriedades:

• id;
• publish_date: data e hora de publicação do banner;
• title: um título para o banner;
• description: (OPCIONAL) breve descrição para o banner;
• image: nome da imagem para servir como peça de divulgação;
• category: uma flag que vai sinalizar uma categoria para o banner, ex: Home, Lateral e etc;
• url: (OPCIONAL) url de destino para eventos de clique no banner;
• status: campo booleano que representa o status do banner;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• deleted_at: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• deleted_by: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Regras de Negócio

• A propriedade category será utilizada para categorizar os banners e nos dar a flexibilidade de poder colocá-los em vários áreas diferentes e independentes do portal;

• As imagens dos banners deverá ser enviadas para nosso servidor;

• As imagens enviadas deverão ser redimensionadas para tamanhos "mais amigáveis" para web;

Definição

Implementação da autenticação dos administradores e moderadores do portal da comunidade. O usuário deverá entrar com seu e-mail e senha para ter acesso a área administrativa.

Entity, Repository e Migration

Deve-se ser criada a Entity Usuario, seu Repository e Migration com as propriedades:

• id;
• nome: nome legível do usuário;
• email: e-mail para autenticação e envio de mensagens;
• senha: senha de acesso do usuário criptografada;
• grupo: campo de texto que representará o grupo de usuário. Possíveis valores: ROLE_ADMIN, ROLE_MODERADOR, ROLE_REDATOR e ROLE_MEMBRO
• avatar: (OPCIONAL) campo para o nome da imagem que representa o avatar do usuário;
• token: (OPCIONAL) campo que representa o token para recuperação de senha;
• sessao: (OPCIONAL) campo que representa o hash de sessão do usuário autenticado;
• status: campo booleano que representa o status do usuário;
• criado_em: campo de data/hora que representa a data e hora de criação do registro;
• criado_por: ID do usuário que criou o registro;
• atualizado_em: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• removido_em: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• removido_por: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Fixture

Deverá ser criado uma Fixture com um usuário com as informações abaixo:

• id = 1;
• nome: Administrador
• email: [email protected]
• senha: rapaduradopoder (senha criptografada!)
• grupo: ROLE_ADMIN
• avatar: NULL
• status: 1
• criado_em: NOW()

Definição

Criar funcionalidades de Create, Read, Update e Delete de Membros da comunidade. Como tratam-se de 2 tabelas relacionadas, é importante que nas ações create e update sejam salvas os dados do Membro e também do Usuário.

Inserir um item de navegação para a consulta de Membros.

Entity, Repository e Migration

Deve-se ser criada a Entity Membro, seu Repository e Migration com as propriedades:

• id
• user_id: ID do usuário que representa o membro;
• name: Nome do membro;
• last_name: Sobrenome do membro;
• status: campo booleano que representa o status do membro;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• github_url: (OPCIONAL) username do membro no github;
• phone: (OPCIONAL) ddd + telefone de contato do membro (sem caracteres especiais);
• Informações do usuário. Vide a Issue #12

Regras de Negócio

• Os usuários que tem vínculo com membro, deverá OBRIGATORIAMENTE ter o grupo de usuário/role setado como ROLE_MEMBRO;

Estive pensando em colocar o AdminLTE 2 como o layout para nossa área administrativa. Porém, como nosso intuito aqui é também aprender, pensei em colocar algum template semelhante, que seja FREE e com Bootstrap 4.

Alguém sugere algum nesses moldes ?

Definição

Implementação de uma tela para moderação e acompanhamento dos Posts enviados pelos membros da comunidade. Inserir um item de navegação para essa tela.

Regras de Negócio

• Somente o dono do post poderá fazer alterações/correções no post, ou seja, o administrador/moderador só poderá visualizar o conteúdo do post.

• Os posts cadastrados na área dos membros deverão inicialmente ser setado com status Em Análise;

• Nessa tela o administrador/moderador poderá executar as ações: Aprovar, Reprovar e Enviar para Correção com uma campo opcional para que seja feito um comentário;

• É necessário ter um histórico da mudança dos status dos posts para futuras consultas;

• Para cada mudança de status deverá ser enviado um e-mail para o membro dono do post;

Entity, Repository e Migration

Deve-se ser criada a Entity Post, seu Repository e Migration com as propriedades:

• id;
• category_id: ID da categoria do Post;
• publish_date: data e hora para publicação do post;
• title: título para o post;
• content: conteúdo do post;
• slug: string com o slug do título do post;
• tags: lista de tag's para o post;
• status: status do post, podendo ser: Em análise, Publicado e Rejeitado;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• deleted_at: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• removido_por: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Deve-se ser criada a Entity CategoryPost, seu Repository e Migration com as propriedades:

• id;
• name: nome da categoria do post;
• slug: string com o slug do nome da categoria;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;

Deve-se ser criada a Entity Tag, seu Repository e Migration com as propriedades:

• id;
• name: nome da tag;
• slug: string com o slug do nome da tag;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;

Deve-se ser criada a Entity TagPost, seu Repository e Migration com as propriedades:

• post_id;
• tag_jd

Estrutura Organizacional das Funções

Projeto Novo Site Comunidade PHP com Rapadura

• Product Owmer
• Scrum master
• Designer
• Front-End
• Back-End
• Documentação

---

PRODUCT OWNER

• Kilderson Senna @dersonsena

SCRUM MASTER

• Aline Chaves @alinechavessilva

DESIGNER

• Junior Oliveira @Junior-Shyko

FRONT-END

• William Correa @wilcorrea
• Manoel Freitas @manoel-freitas

BACK-END

• Luítame de Oliveira @Luitame
• Jholdy Damasceno @jholdy
• Kilderson Senna @dersonsena
• Marcos Vinicios @Vini85428026

DOCUMENTAÇÃO

• Cleilson Pereira @marcialwushu
• Rodrigo Cavalcante @rodrigo131045

Definição

Criar funcionalidades de Create, Read, Update e Delete dos Patrocinadores/Apoiadores da comunidade.

Entity, Repository e Migration

Deve-se ser criada a Entity Partner, seu Repository e Migration com as propriedades:

• id;
• name: nome para o patrocinador/apoiador;
• slug: string com o slug do nome do patrocinador/apoiador;
• image: nome da imagem/logomarca do patrocinador/apoiador;
• type: flag que sinaliza se é um patrocinador ou um apoiador;
• status: campo booleano que representa o status do registro;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;

Definição

Implementação de uma tela para moderação e acompanhamento das Vagas de Emprego enviadas por QUALQUER membro da comunidade. Inserir um item de navegação para essa tela.

Regras de Negócio

• As vagas ofertadas na área dos membros deverão inicialmente ser setado com status Em Análise;

• Nessa tela o administrador/moderador poderá executar as ações: Aprovar, Reprovar e Enviar para Correção com uma campo opcional para que seja feito um comentário;

• É necessário ter um histórico da mudança dos status das vagas para futuras consultas;

• Para cada mudança de status deverá ser enviado um e-mail para o membro que ofertou a vaga;

Entity, Repository e Migration

Deve-se ser criada a Entity JobOffer, seu Repository e Migration com as propriedades:

• id;
• category_id: ID da categoria da Oferta de Emprego;
• validate_date: (OPCIONAL) Data e hora para a validade da oferta de emprego;
• title: título para da vaga de emprego;
• description: descrição detalhada da vaga de emprego;
• slug: string com o slug do título da oferta;
• url: (OPCIONAL) URL para casos de uma vaga em sites de terceiros ou parceiros;
• status: status da oferta, podendo ser: Em análise, Publicado e Rejeitado;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;
• deleted_at: (OPCIONAL) campo de data/hora que representa a data e hora da deleção do registro;
• deleted_by: (OPCIONAL) ID do usuário que removeu/deletou o registro;

Deve-se ser criada a Entity CategoryJobOffer, seu Repository e Migration com as propriedades:

• id;
• name: nome da categoria da Oferta de Emprego;
• created_at: campo de data/hora que representa a data e hora de criação do registro;
• created_by: ID do usuário que criou o registro;
• updated_at: (OPCIONAL) campo de data/hora que representa a data e hora da última atualização do registro;

Definição

Criar funcionalidades de Create, Read, Update e Delete de usuários. As informações do usuário estão na Issue #12 . Inserir um item de navegação para a consulta de usuários.

Regras de Negócio

• Não será permitido que um usuário possua um endereço de e-mail + Grupo de Usuário de outro usuário já cadastrado no sistema, ou seja, deverá haver uma verificação de E-mail + Grupo de Usuário;

• Deverá haver um campo para repetição de senha par verificação da mesma;