Construindo uma Rede Social

[João Batista Neto 448]

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: Salt

Campos:

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.

[João Batista Neto 448]

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.

[João Prado 64]

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.

[Untill 0]

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.

[Daniel Ribeiro 4]

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!

[João Prado 64]

Pessoal, para quem vai participar do design de nossa rede social, criei um tópico em Design Geral para iniciarmos os trabalhos.

 

http://forum.imasters.com.br/index.php?/topic/402865-construindo-uma-rede-social-iniciando-o-projeto/

[Daniel Ribeiro 4]

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:

 

• usuario
• usu_id
• usu_name
• usu_real_name
• usu_email
• usu_password
• usu_site
• usu_reputation

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:

 

• ordem_servico
• os_id
• os_usu_id

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.

[João Batista Neto 448]

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.

[h4v3st 1]

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).

 

Link: Construindo uma rede social - MySQL.

[Daniel Ribeiro 4]

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.

[João Batista Neto 448]

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.

 

;)

[GabrielFerrari 41]

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.

[Daniel Ribeiro 4]

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.

[Bruno Augusto 417]

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...

[João Batista Neto 448]

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.

[Daniel Ribeiro 4]

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.

[João Prado 64]

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?

[Untill 0]

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.

[João Batista Neto 448]

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.

[Daniel Ribeiro 4]

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?