Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Olá pessoal,
Começaremos a construir a aplicação pelo cadastro do usuário, sistema de autenticação e sua página de perfil; Abaixo as primeiras tarefas para a construção da aplicação:
Design:
Design da tela de login:
A interface deve conter duas caixas, uma para login do usuário, caso já seja cadastrado e outra para que o usuário possa se cadastrar.
A caixa de login, deverá conter um campo para email do usuário e outro para senha; Deverá conter também um checkbox para permitir que o usuário mantenha-se logado
A caixa de cadastro deverá conter, apenas, um campo para email; Quando o usuário colocar seu email nessa caixa, enviaremos um email de validação contendo um link. Quando o usuário validar seu email teremos a tela de cadastro de usuário.
Design da tela de cadastro de usuários:
Nome de exibição (esse nome será único, então precisará ser verificado a disponibilidade).
Nome Real.
Email (esse será o email validado e será somente leitura, o usuário não poderá modificar esse campo).
Senha.
Confirmação de Senha.
Design da tela de perfil:
A tela de perfil privada deverá conter, além dos campos do cadastro (nome de exibição, nome real e email), os seguintes campos:
Avaliação (apenas leitura: média da pontuação dada por outros membros).
Site Pessoal (apenas um link).
Status. (campo curto para postagem de mensagens simples).
Ideias iniciadas (lista de ideias que o usuário iniciou).
Botão "Ter uma nova ideia" (permitirá ao usuário ter uma nova ideia).
Ideias apoiadas.
A tela de perfil pública deverá conter os seguintes campos:
Avaliação (apenas leitura: média da pontuação dada por outros membros) na tela de perfil pública, esse outro usuário poderá avaliar o perfil do membro.
Site pessoal (apenas link).
Ideias iniciadas (com um botão em cada ideia: "Apoiar ideia").
**Webstandars:
**
HTML e CSS do design elaborado
Verificação de disponibilidade do nome de usuário via Ajax.
Com exceção da verificação do nome de usuário, que será via Ajax, todos os outros formulários serão postados normalmente.
Banco de dados:
Nome da tabela: User
Campos:
idUser (chave primária, auto numeração)
userName (chave única, indexável)
userRealName (indexável)
userEmail
userPswd (hash da senha do usuário)
userSite (URL do site do usuário)
userReputation (avaliação dada por outros membros, esse campo terá valor máximo como 100)
Nome da tabela: SaltCampos:
idSalt (chave primária, auto numeração)
idUser (id do usuário)
saltValue (campo de 128 caracteres para um salt de 512 bits)
PHP:
Construção de uma base HMVC, e o MVC para as requisições de usuários.
O objetivo desse Sprint Planning Meeting é discutir as questões técnicas para a elaboração do cadastro e autenticação de um usuário. Não lidaremos com status, ideias, grupos e mensagens nesse momento.
Ao final desse Sprint Planning Meeting teremos nosso primeiro Sprint, cujo objetivo será logar ou cadastrar um usuário no sistema e ter um "framework" para criação das outras etapas do projeto.
Precisamos construir um design simples, prático e intuitivo ao usuário e uma base HMVC para a aplicação, que deverá ser reutilizável para todos os outros módulos.
Opa, o projeto esta andando :D
Irei contribuir com o design, e dependendo de como estiver o tempo posso dar um help em Webstandards caso precisem.
Posso ajudar em todas as tarefas listadas, porém meio que me abdico da programação em PHP devido ao fato de que grande parte do publico presente no projeto pretende focar na programação. Conforme informado no tópico, enviei uma PM com meu e-mail apara adição a lista de commiter's.
Fala João!
Fico na parte de PHP do projeto.
Pode me cadastrar lá para ser commiter com o e-mail enviado por PM.
Abraço!
Pessoal, para quem vai participar do design de nossa rede social, criei um tópico em Design Geral para iniciarmos os trabalhos.
Tenho uma sugestão a fazer com relação à padronização de alguns fatores para nosso projeto.
Sugiro que, quando formos nos referenciar aos nomes dos campos de cada tabela, usemos um prefixo baseado no próprio nome da tabela.
Exemplo:
Para esta padronização, o prefixo é composto pelas três primeiras letras do nome da tabela.
Caso o nome da tabela tenha nome composto de duas ou mais palavras, usa-se o padrão abaixo:
O nome dos campos é composto pela primeira letra de cada palavra que compõe o nome da tabela. Desta maneira, temos uma melhor organização da base de dados e, consequentemente, um melhor mapeamento na estruturação desses dados no core da aplicação.
Justificativa: Teremos que trabalhar, diversas vezes (pra não dizer sempre), com os nomes reais dos campos das tabelas, ou suas variações nas diferentes camadas da aplicação. Desta maneira, jamais teremos problemas com nomes parecidos em duas tabelas ou algo deste tipo.
>
Tenho uma sugestão a fazer com relação à padronização de alguns fatores para nosso projeto.
Desta maneira, temos uma melhor organização da base de dados e, consequentemente, um melhor mapeamento na estruturação desses dados no core da aplicação.
Justificativa: Teremos que trabalhar, diversas vezes (pra não dizer sempre), com os nomes reais dos campos das tabelas, ou suas variações nas diferentes camadas da aplicação. Desta maneira, jamais teremos problemas com nomes parecidos em duas tabelas ou algo deste tipo.
Concordo com a padronização,
Na lista de tarefas, como poderá ser visto, eu usei o seguinte padrão:
Tabela: NomeDaTabela
Campos:
Chave primária: idNomeDaTabela
Outros Campos: nomeDaTabelaNomeDoCampo
Relacionamentos: idNomeDaTabelaDeOrigem
Como pode ser visto, o problema de nomes parecidos não existe, porém, ao contrário do sugerido, foi utilizado CamelCase.
Isso porque, no PHP usaremos exatamente o mesmo padrão no código, camelCase para propriedades e métodos e CamelCase para classes.
EDIT: Se preferirem utilizar o _, não tem problemas por mim, mas a padronização é fundamental.
Daniel boa dica. Eu procuro sempre trabalhar assim, iniciando o nome da tabela+nome do campo.
Eu criei o tópico na área de MySQL pra quem irá ajudar no desenvolvimento da base de dados (e quem quiser acompanhar também).
Bom, a sugestão está feita. Fica a cargo da comunidade de desenvolvedores e colaboradores do projeto decidirem qual das duas opções utilizar.
OBS: Acho interessante a sua maneira de padronização, João. Só estou acostumado a trabalhar da outra maneira, mas sempre disposto a mudar.
>
OBS: Acho interessante a sua maneira de padronização, João. Só estou acostumado a trabalhar da outra maneira, mas sempre disposto a mudar.
Sim, eu editei meu último post.
Se os senhores preferirem trabalhar de uma forma específica, por mim tudo bem, aceitarei qualquer método que tiver como objetivo padronizar.
;)
A parte de Webstandards para mim é tranquilo ajudar.
Quanto ao PHP e MySQL eu venho estudando e gostaria muito de fazer parte para conseguir mais conhecimento.
>
A parte de Webstandards para mim é tranquilo ajudar.
Quanto ao PHP e MySQL eu venho estudando e gostaria muito de fazer parte para conseguir mais conhecimento.
Não sei o que o João Batista Neto pensa a respeito disso, mas creio que essa seja a alma do negócio.
Como teremos um planejamento controlado e um bom sistema de versionamento, sempre teremos alguém para manipular as transações entre desenvolvedor x desenvolvimento.
Dou a maior força para que todos pariticipem.
Se com "enquete não está funcionando adequadamente" você estiver se referindo a ela não estar "abrindo" o popup com os resultados, infelizmente não é de hoje e não é só neste fórum.
Aparentemente o IPB anda meio lelé da cuca nessas últimas versões :P
Mas enfim, já que me empurrar em Design é a mesma cois que me empurrar precipício abaixo, eu ajudo com programação (pelo menos o que entender :P )
Depois do layout pronto posso ajudar com aquelas análises chaaaaaatas e exteeeeensas que eu faço quando estou inspirado. :lol:
P.S.: No outro tópico ficou decidido quanto a pelo menos o usp de algum framework JavaScript? JavaScript "no braço" é meio complicado...
>
P.S.: No outro tópico ficou decidido quanto a pelo menos o usp de algum framework Javascript? Javascript "no braço" é meio complicado...
Quanto a Javascript, podemos utilizar JQuery ou algum outro framework que preferirem, porém, terá que se decidir por um framework específico.
Eu cheguei a sugerir GWT no tópico anterior, mas acho que o problema foi o uso do Java.
Enfim, se preferirem utilizar JQuery, legal; Se preferirem EXTJS, show também.
Eu sugiro a utilização do ExtJS para a interface gráfica.
É um excelente framework, e tenho experiência em sua utilização.
Posso servir de supervisor para os desenvolvedores da parte de interface.
Mais uma vez, vocês que decidem.
Pessoal, me surgiu uma dúvida aqui.
No início o cadastro será por meio de convites, então minha sugestão é que na página de cadastro tenha um campo de texto onde quem estiver efetuando o cadastro deverá preencher com um código que é enviado para seu e-mail quando for convidado.
O que acham?
Se formos citar a seleção de uma framework para JS, sem dúvidas estamos falando de JQuery, não existe sequer motivos para discutir isso.
>
No início o cadastro será por meio de convites, então minha sugestão é que na página de cadastro tenha um campo de texto onde quem estiver efetuando o cadastro deverá preencher com um código que é enviado para seu e-mail quando for convidado.
Isso pode ser automático,
Vamos enviar um email, que deverá ser validado antes de efetuar um cadastro, esse email pode conter o próprio código de convite; Isso evita que o usuário precise preencher um campo com um código (muitas vezes, um hash, feio para muitos usuários) e evitamos incluir no cadastro, campos que poderão ser removidos no futuro.
>
Se formos citar a seleção de uma framework para JS, sem dúvidas estamos falando de JQuery, não existe sequer motivos para discutir isso.
Porquê você acha isso?
Extjs é uma ferramenta poderosa, onde ganhamos tempo em relação a designer, seria interessante utiliza - lo na parte administrativa do sistema.
Em relação a PHP estão pensando em utilizar algum FrameWork? Por exemplo o Zend FrameWork, assim teremos um sistema totalmente em OO, MVC e todos falaram a mesma lingua.
O que acontece muito em projetos grandes quando se tem muitos programadores é cada um sair programando do seu jeito, sem nenhum padrão depois ajunta tudo e tá pronto!
mas depois para dar manutenção numa coisa dessas é horrivel, zuado mesmo. O que eu queria dizer é para adotado um padrão para desenvolvimento para isso não acontecer no projeto, agora isso pode ser meio bobo, mas é uma medida que temos que tomar logo no inicio do projeto!
http://forum.imasters.com.br/public/style_emoticons/default/joia.gif
>
Extjs é uma ferramenta poderosa, onde ganhamos tempo em relação a designer, seria interessante utiliza - lo na parte administrativa do sistema.
Em relação a PHP estão pensando em utilizar algum FrameWork? Por exemplo o Zend FrameWork, assim teremos um sistema totalmente em OO, MVC e todos falaram a mesma lingua.
O que acontece muito em projetos grandes quando se tem muitos programadores é cada um sair programando do seu jeito, sem nenhum padrão depois ajunta tudo e tá pronto!
mas depois para dar manutenção numa coisa dessas é horrivel, zuado mesmo. O que eu queria dizer é para adotado um padrão para desenvolvimento para isso não acontecer no projeto, agora isso pode ser meio bobo, mas é uma medida que temos que tomar logo no inicio do projeto!
http://forum.imasters.com.br/public/style_emoticons/default/joia.gif
Concordo com relação ao ExtJS.
Sobre o padrão de desenvolvimento, iremos adotar um, sem dúvida nenhuma.
Não há condições de trabalhar sem um padrão no mercado atual.
A necessidade de se utilizar um Framework, todavia, acho bastante contraditória.
>
>
Se formos citar a seleção de uma framework para JS, sem dúvidas estamos falando de JQuery, não existe sequer motivos para discutir isso.
Porquê você acha isso?
Na minha opinião JQuery sem dúvida é um ótimo framework, quando se trata de não ter problemas de incompatibilidade dos navegadores atuais, sem conta na facilidade de se trabalhar com ele, reutilização e redução do código e sem contar que existe uma grande quantidade de plugins criados por outros desenvolvedores!
acredito que o Untill e outros aqui pensaram nisso tb!
>
>
Se formos citar a seleção de uma framework para JS, sem dúvidas estamos falando de JQuery, não existe sequer motivos para discutir isso.
Porquê vocacha isso?
Porque dentre todas as outras, esta é a que a maioria das pessoas conhece. Como você também sou utilizador da Ext e se estivesse desenvolvendo este projeto "sozinho" também a usaria. Sabemos que muitas das pessoas que utilizam frameworks para javascript, iniciaram ou já utilizaram a JQuery, portanto esta acaba por ser a melhor escolha.
>
Porque dentre todas as outras, esta é a que a maioria das pessoas conhece. Como você também sou utilizador da Ext e se estivesse desenvolvendo este projeto "sozinho" também a usaria. Sabemos que muitas das pessoas que utilizam frameworks para javascript, iniciaram ou já utilizaram a JQuery, portanto esta acaba por ser a melhor escolha.
Neste ponto você tem razão.
O JQuery é bem mais difundido entre os programadores iniciantes do que o ExtJS, que é uma ferramenta para quem já conhece a linguagem, inclusive orientada a objetos.
Mas se formos trabalhar em uma área administrativa, continuo defendendo o ExtJS.
A interface para o usuário pode, com certeza, ser feita com JQuery.
>
>
Porque dentre todas as outras, esta é a que a maioria das pessoas conhece. Como você também sou utilizador da Ext e se estivesse desenvolvendo este projeto "sozinho" também a usaria. Sabemos que muitas das pessoas que utilizam frameworks para javascript, iniciaram ou já utilizaram a JQuery, portanto esta acaba por ser a melhor escolha.
Neste ponto você tem razão.
O JQuery é bem mais difundido entre os programadores iniciantes do que o ExtJS, que é uma ferramenta para quem já conhece a linguagem, inclusive orientada a objetos.
Mas se formos trabalhar em uma área administrativa, continuo defendendo o ExtJS.
A interface para o usuário pode, com certeza, ser feita com JQuery.
Ai, eu entro de acordo com você, porem se formos limitar o projeto, a pessoas que conheçam, orientação a objetos, frameworks, e etc, acabaremos seletando um grupo de 5/10 pessoas e no final das contas estaremos se opositando a ideologia inicial do projeto.
Parece que a enquete pública não está funcionando adequadamente, então, além de votar na enquete, postem a área que desejam participar abertamente.
O repositório para controle de versão foi criado no Google Code com o codinome imns http://forum.imasters.com.br/public/style_emoticons/default/seta.gif http://code.google.com/p/imns
Por motivos de segurança, aqueles que desejarem ser comitters no repositório, deverão enviar uma MP para mim com a conta Google que desejam ser cadastrados no repositório.