imastersdev / oportunidades Goto Github PK

• Definir local das pastas para arquivos estáticos e views.
• Criar estrutura de template simples para aplicar layout.

Acho bacana definirmos uma #hashtag pra utilizarmos no twitter e em outros serviços social pra identificar as discussnoes sociais do hangout. Acho que ganharemos bastante no tracking futuro do projeto.

olá pessoal.

vi que o front já esta pronto.
O que esta faltando para exibir o front-end?

O que acham de criar uma lista de tarefas e começarmos a finalizar as coisas?

Abraço

Assisti o dally meet onde o @drgomesp sugere em mudar o diretório DataAccess para Domain.

Vi que ninguém concordou e acredito que seja pelo fato do projeto não contemplar DDD.
A ideia de usar DDD seria interessante no inicio, mas como ja tem muita coisa pronta é totalmente inviável.

Gostaria de saber do @drgomesp se ele tinha sugerido usar de fato DDD ou simplesmente mudar a o nome do diretório de DataAccess para Domain.

criar a tabela no banco de dados selecionado para poder persistir as positions cadastradas

Qual será adotado ?

Sugestão:

• branches:
  • dev
    • feature
    • release
  • master
    • release

Pessoal o que acham de uma presentation logic com XML, XML Schema (para validação do XML) e XSL para transformação do XML em HTML 5?

Não sei se isso deveria ser uma issue mas é bom deixar anotado. Seria interessante o sistema ser integrado com as redes sociais para compartilhar alguma oportundiade que vc viu com um amigo seu.

Inicialmente creio que apenas o ShareThis resolve.

Criação do domínio ophportunidades.com.br e ophportunidades.org.br

@netojoaobatista o testInsertPosition não poderia ser quebrado em dois cara, ou seja,
testInsertPosition = testa o metodo insert do objeto Position
e depois teriamos
testGetById = testa o metodo getById do objeto Position

eu sei que você já aproveitou o id do registro que acabou de inserir,
mas depois quando o teste falhar acho seria mas claro ter eles separados.

Pessoal, acho interessante utilizarmos o Vagrant para padronizar o ambiente de desenvolvimento e, eventualmente, o de staging e produção.

Dessa forma, basta criarmos uma VM padrão, com as versões do PHP, MySQL e qualquer outra ferramenta que formos utilizar.

Assim, mantemos um Vagrantfile no repositório, com as configurações de setup automáticas com Chef ou Puppet, para que qualquer um que queira contribuir com o projeto tenha o ambiente configurado pronto para desenvolver em pouquíssimo tempo.

Seria interessante que o Desenvolvedor pudesse logar com o github para montarmos um perfil do Desenvolvedor mais condizente com o que ele possui de projetos.

Exibição das oportunidades cadastradas no sistema em ordem cronológica de cadastro (decrescente).

[Idéia de @kinncj]

O profissional poderá associar seu perfil aos perfis das redes sociais, como por exemplo:

1 - github
2 - LinkedIn
3 - Gitorious
4 - BitBucket

Mais algum?

configurar o ambiente de desenvolvimento para dar sequencia

Suportar o http://travis-ci.org pra integração contínua.

Criacao da entidade
criacao de objetos corretatos a persistencia.

Fica mais claro para achar o codigo.

Pessoal, estou removendo o composer.lock por causa daquele problema que tivemos ontem. Acho melhor deixar o diretório de trabalho limpo, para que o pessoal possa usar o composer.phar install e configurar as coisas localmente.

Uma das grandes dificuldades dos tempos atuais é a locomoção.
seria legal se pudessemos tambem apresentar esse detalhe, talvez com linhas de onibus, tempo de carro, transito e outras coisas que são importantes para a maioria dos profissionais na hora de decidir por um emprego, afinal, vai se deslocar todos os dias para aquela area.

Talvez para um segundo milestone, seria interessante a opção de modificar o status de uma oportunidade de 'em aberto' para 'vaga preenchida', ou até mesmo a exclusão da mesma pelo autor assim que atendida.

Isto ajuda a evitar que tanto o anunciante de uma oportunidade recente, mas já preenchida, continue recebendo e-mails sobre a mesma, quanto o candidato pra que não perca tempo.

Esse é um problema particular meu mas acredito que valha a pena uma pincelada para quem pratica o uso das classes-base para todas as outras e ainda assim tem uma real necessidade em utilizar o Observer

Pode ser interessante ter uma feature onde o Dev possa enviar uma pergunta diretamente ao dono da vaga.

Galera, não queria interferir mas, no meu conceito, é correto fazer validação dentro das entidades? estas não deveriam somente representar os dados?

Ficou meio estranho pra mim :(
Abraços.

seria legal poder votar, no esquema de 1-5 em algumas caracteristicas da empresa como inovadora, proativa, qualidade dos relacionamentos, incentivo a atualização profissional, plano de carreira e eoutras.

configuracao do banco de dados
criacao da tabela para vagas

Vocês acham interessantes deixar comentários abertos para as oportunidade?

Acho que é óbvio que adotaremos todas as PSRs, mas fora isso precisamos padronizar mais alguma coisas.

• Codaremos em inglês ou português? (Prefiro ingluês)
• Mensagens de commit em inglês ou português? (Prefiro português mais aí teremos que forçar uma configuração no git)
• Encoding dos arquivos? (Prefiro UTF-8)
• Line endings dos arquivos? (Prefiro Unix-like)

Tem mais alguma coisa que estou esquecendo?

No hangout da scrum meeting definimos o @iannsp , no fim acho que essa issua é mais pra formalizar isso. Todos de acordo?

PS: sim, sabemos que ele é gordo.
PPS: sim, sabemos que ele fará várias gordisses.

Nosso projeto precisa urgente de um README lindão usando Markdown descrevendo o que faremos ou o que dissemos até agora no vídeo.

Links para os outros hangouts, posts ou tudo mais também seriam interessantes.
Pra não sujar o controle de versão, vamos definir o que queremos no README?

Sendo um painel de vagas do PHP Brasil, teremos vaga de todo o país.

Logo, seria interessante ter uma API para que as comunidades de cada estado possam buscar as vagas e inserir as de interesse em seus próprios sites.

É uma forma de todas as comunidades aproveitarem o serviço.

Opa!
Galera nem sei se é aqui que posta esse tipo de coisa, mas só vamos fazer commits quando os testes passarem... se não complica a vida do pessoal.
Atualizei os arquivos e tem um teste dando erro.
Sacanagem isso :(

Após autenticado, o usuário poderá registrar novas oportunidades para que sejam listadas no sistema.
Essencialmente as oportunidades deverão ter título e descrição.

permitir que o formulario passe a persistir os dados da vaga.

Temos que ter o deploy em algum lugar, temos algumas alternativas:

• Pagodabox
• PHPFog
• Azure
• Amazon

O que preferem?

Opa!
Eu fiz uma página para configurar no Windows, vocês acham isso útil?

https://github.com/iMastersDev/oportunidades/wiki/Configurando-o-Ambiente

É importante diferenciar as oportunidades bacanas das ruins. É sacanagem identificar as ruins de maneira explícita, até porque o critério pra isso é muito pessoal.

Então vamos dar a oportunidade de quem estiver cadastrado ou identificado ou quaquer coisa de dar uma espécie de like em uma vaga. Indicando a vaga como bacana.

O que acham?

Caros, seria útil que as labels representassem o status do ticket, tenho algumas idéias mas não me apaixonei muito por nenhuma label em especial:

• dev: pronto pra desenvolver
• bug
• feature: Quando alguém quiser alguma feature, precisa de feedback do PO ou do time.
• dúvida: Quando alguém tiver alguma dúvida, Será que esse cara é realmente necessário?
• in development: tem um time (pair) trabalhando nisso agora

Considerando a importância que o Linkedin vem tendo, principalmente na nossa área, ter uma conta lá é essencial, por isso acho mais do que interessante ser obrigatório o Login via a API deles.

http://developer.linkedin.com/documents/sign-linkedin

Pessoal, temos que agilizar nossas reuniões diárias;

• Estabelecer um horário;
• Estabelecer tempo de duração;
• Usar um token durante a reunião;
• Estabelecer/cobrar entregáveis.

Any thoughts?

Em algum momento (não lembro a issue, ou se foi apenas no hangout) definimos que os códigos seriam PSR2 https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

Acredito que uma maneira de garantirmos isso primeiro é colocar o php_codesniffer nas nossas máquinas de desenvolvimento.

Já existem alguns componentes prontos no Packagist para isso, como o https://packagist.org/packages/squizlabs/php_codesniffer

Um problema é que ele não tem como padrão a PSR2 como standard default.

Por isso fiz o seguinte: https://packagist.org/packages/rogeriopradoj/php-code-sniffer

Se concordarem, vou colocar ele no nosso composer json no require-dev, blz?

Não sei se ainda é o momento, mas acredito que seria interessante deixar defindo quais componentes serão usados nessa primeira etapa do projeto.

Eu escolheria:

Respect/Rest
Respect/Validation
Respect/Config
Doctrine
Twig

Na lista de oportunidades (#15) exibir o avatar do cadastrante a partir do email (buscando a imagem no gravatar).

permitir o campo descricao no objeto de position para poder anotar o nome da vaga e sua descricao detalhada.

• Mensagem de assertEquals() em testSetTitleWithValidDataShouldWork():
  Rerturned -> Returned
• Annotation em testSetTitleWithInvalidDataShouldThrownAnException():
  @expectedExpcetionMessage -> @expectedExceptionMessage
• Mensagem de assertEquals() em testShouldExistsSetterForDescription():
  Rerturned -> Returned

Primeiro quero parabenizar todos os envolvidos no projeto pelo ótimo trabalho que vocês vem realizando transmitindo conhecimento para toda a comunidade.

Sei que o foco deste projeto em si é mostrar como são feito os teste, mas se quisermos que a aplicação seja utilizada no "dia-a-dia" ela precisa de uma interface que facilite o acesso as funcionalidades da mesma. Vocês já tem alguma ideia em como vão organizar esta parte?

Bom, eu não sou designer, mas eu estava com um tempo ocioso aqui e tomei a liberdade de expressar em layers a minha visão do ophortunidades:

O que acham?

Deverá ser criado o Vagrantfile necessário para subir uma VM com as seguintes configurações:

• CentOS
• PHP (stable)
• MySQL (stable)
• Apache2

Será utilizado o Puppet para a definição das configurações.

PS: Falta decidir os vhosts que serão utilizados, caso necessário.

o formulario html para cadastro de vagas

Alguns arquivos estão identados com tabs.