Paulo Eduardo

Essa semana o blog oficial do google divulgou o que seria o mais novo concorrente da wikipedia, o Google Knol.

Lançado numa versão somente para convidados o projeto permite a criação dos chamados Knol`s (unit of knowledge, unidades de conhecimento) por usuarios cadastrados no sistema, diferente da wikipedia os artigos criados só poderão ser editados pelo proprio criador, e esses poderão ser avalidos por outros usuarios, a busca por artigos deve avaliar a relevancia dos artigos de acordo com os termos de busca e as avaliações do usuario.

O usuario que criar o artigo tambem poderá permitir que o google vincule material publicitário ao artigo e uma parte da renda da divulgação publicitaria deverá ser destinada aos criadores do texto.

O google divulgou tambem uma screenshot do visual da sua nova aplicação que nem foi completamente lançada mas já levantou os animos dos interessados no assunto.

Alem de tudo isso a screenshot divulgado pelo proprio google mostra uma área onde o Knol pode ser comentado, funcionalidade essa que não está presente na wikipedia.

Confirá aqui a screeshot do Knol

Post rápido pra falar sobre mais algumas novidades no blog.

Foi feito o update para a versão 2.3.1 do wordpress, a versão já foi lançada a algum tempo, mas ainda não tinha feito o upgrade, como já era de se esperar do wordpress, simples rápido e facil, não fosse eu ter errado na hora de subir o config com as informações do banco de dados local da minha maquina ao inves do com os dados do servidor.

Obviamente o wordpress me retornou um erro e eu logo corrigi o problema, se não fosse esse pequeno imprevisto a atualização teria sido feita em dois cliques.

A principal mudança notada até agora nessa versão do wordpress por mim está na area administrativa, principalmente na seção de gerenciamente de blogroll e na possibilidade de colocação de tags nos posts (alguns já utilizavão essa função com auxilio de plugin).

Fiz algumas correções no layout tambem, pois como era meu primeiro tema desenvolvido para wordpress ainda haviam alguns errinhos (falta de experiencia que com o tempo vai sendo corrigida) corrigi tambem a area de monetização do blog (agente tem que viver de alguma coisa mesmo, espere que de algum retorno).

Por enquanto é isso, em breve devo escrever sobre o processo de criação do novo alyout como já havia sido prometido.

Blogged with Flock

Tags: Novidades

A algum tempo sem escrever, mas estava desenvolvendo essa novidade de fim de ano para o blog, acabei de instalar o novo layout do blog, foi meu primeiro template para wordpress desenvolvido, por isso alguns erros podem ocorrer durante o percurso.

Desenhei o layout a partir de uma estrutura desenhada por mim usando alguns elemento do layout anterior, que era desenvolvido pelo N.Design Studio.

Junto com o novo layout vem o primeiro post enviado pelo sistema de postagem incluido no flock que estou usando atualmente como browser padrão

Nos proximos posts falarei um pouco sobre a experiencia de desenvolver o layout para wordpress, sobre blogar usando flock e sobre o proprio flock.

Blogged with Flock

Tags: Outros

Ha algumas semanas o orkut estava anunciando o seu novo layout, mas agora é pra valer, ao que parece todos os usuarios da comunidade eletronica já estão usando o novo layout (me corrijam se eu estiver errado).

Minhas primeiras consideraçoes pessoais:

O Visual

Pelo que pude perceber é um consenso quase global que visualmente o novo orkut é muito mellhor que o antigo, o aumento nas areas brancas do site dá muito mais levaza a nova cara, quebrando bastante o antigo azul global que tomava conta do antigo layout e que já estava “enjoando” seus usuarios.

Cantos arredondados tambem foram adcionados a algumas areas de informação proporciando um melhor fluxo de navegação.

Organização do Conteudo

O menu lateral agora concentra quase todas as funções da pagina o que facilita bastante na busca pelo local desejado.

A seçao de aniversários proximos ganhou alinhamento lateral entre os aniversarios, com isso será mais dificil encontrar listas imensas de aniversários como ocorria quando esses eram listados um em baixo do outro.

O que perdeu bastante destaque nessa atualização do orkut foram os atalhos para mensagens, fotos, comentarios e etc que se encontram logo abaixo do apelido do usuario, nessa nova versão com icones pequenos e alinhados numa unica linha.

O codigo

Não me lembro ao certo de como era o antigo codigo fonte gerado, mas levando se em considerção que o orkut é uma comunidade virtual onde diversas pessoas entram com conteudo de lugares diferentes, recados. depoimentos, textos do perfil e etc, manter um codigo totalmente semântico sem nenhum erro de marcação é uma tarefa quase que impossivel.

A nova versão tem sim seus erros de codigo, e algumas areas sem uma semantica totalmente definida marcadas somente com “divs”, tabelas ainda são usadas para posicionamento dos elementos de maneira um tanto quanto incorreta, como no caso de amigos e comunidades que não sendo dados tabulares deveriam ser marcados de maneira diferente, porem o uso dessas tabelas não é totalmente exagerado.

Conclusão

Ainda ha o que melhorar, mas essa atualização já resolveu alguns dos principais problemas anteriores do orkut.

PS: A velocidade de carregamento das paginas para mim tambem melhorou, mas as opniões com relação a isso não chegaram em um consenso ainda.

Post rapido de hoje.

Já foi falado aqui, aqui, e em muitos outros lugares sobre o 1º Encontro Brasileiro de Arquitetura de Informação que irá acontecer nos dias 19 e 20 de outubro em São Paulo.

Quem quiser ainda pode enviar seu trabalho, o prazo para submissão foi prorrogado até 05/08/2007, para mais informações entre no site ofical do evento

Esse é o primeiro grande evento a nivel nacional, especificamente sobre arquitetura da informação, uma area que cresceu muito nos últimos tempos, mas que merece ainda muito mais atenção, espero que esse seja um dos passos para esse crescimento.

Continnuando a falar sobre o Diagrama Entidade Relacionamento, nesse post vamos explicar as chaves primarias, estrangeiras e terminar nosso exemplo da locadora.

As Chaves Primarias são o atributo identificador da identidade, por isso sao únicos, ou seja não se repetem, e geralmente sao sequenciais, ou, como são chamados no SGBD, auto-increment, pois caso um atributo seja setado como auto-increment o propeio SGBD se incarrega de, caso um nova linha seja iserida a essa tabela utilizar o numero inteiro positivo imediatamente apos o ultimo utilizado. porem outros dados podem ser usados como chave primaria, como RG e CPF para cadastros pessoais e CNPJ para cadastros de empresas, pois já se sabe que esses atributos respeitam a condição de serem unicos.

Como já foi dito a representação das chaves primarias no DER e feita pelo circulo cheio seguido do nome do atributo identificador, porem na representação usado pelo DBDesigner as chaves primarias são mostradas com um desenho de chave ao lado esuqerdo do nome do atributo identificador, dentro da entidade.

Ainda existe a possibilidade de existirem chaves primarias compostas, ou seja, formadas por dois ou mais atributos, como acontece frequentemente nas entidades fracas, assim como na entidade fraca mostrada na parte anterior, nesse caso a combinação entre todas as chaves primarias não pode se repetir, porem as chaves primarias isoladamente podem se repetir.

Chaves estrangeiras são o elo de ligação entre as entidades, quando ocorre um relacionamento as chaves estrangeiras são “importadas” de uma entidade para outro, por exemplo, na ultima figura da parte anterior, no relacionamento entre cliente e aluguel a chave primaria de cliente é importada pela entidade aluguel, mostrando que aquele aluguel foi feito pelo client.

Porem como saber de que lado será colocado a chave estrangeira? É simples, num relacionamento 1-1 a chave estrangeira pode ficar em qualquer um dos lados, porem no caso de uma entidade para dados opcionais como foi dito anteriormente é recomendavel que a chave estrangeira esteja na entidade com os dados opcionais e nao na entidade com os dados obrigatorios, pois no caso de nenhum dado opcional ser inserido não ha necessidade de criação dessa chave estrangeira.

Já no relacionamento 1-N a chave estrangeira deve ficar do lado N, como no exemplo de clientes e alugueis, onde cada cliente pode fazer varios alugueis, a chave estrangeira fica na entidade alugueis (repare nonvamente no uso da palavra “cada”). Já no caso de relacionamento N-N, onde ocorre a criação de uma entidade fraca, as chaves estrangeiras ficam nessa entidade fraca, formando uma chave primaria composta, sim, é isso mesmo, a chave primaria é formada por duas chaves estrangeiras.

Com essas informações você já é capaz de realizar a sua propria documentação de banco de dados, porem nosso exemplo ainda está incompleto, faltando a seção de reserva de filmes, mostrada na figura abaixo:

Como havia dito na segunda parte da serie, nessa terceira parte iremos falar sobre como relacionar uma entidade com a outra os casos de relacionamento e como identificar cada um.

O relacionamento entre as entidades é reprentado por uma reta ligando as duas entidades com um losango localizado no centro dessa reta.

Seguindo nosso exemplo anterior um cliente, seja ele pessoa física ou jurídica, realiza locações de fitas de video ou DVD, cada locação tem sua identificação e e um atributo data, representando a data de retirada portanto a representação grafica disso, complementando a representação anterior ficaria dessa forma:

Com já havia sido falado, um losango faz a ligação entre as entidades relacionadas, porem a um detalhe que ainda não foi expllicado, a cor de cada uma das metades desse losango, essa divisão de cores representa o tipo de relacionamento entre as entidades.

No caso da locadora, cada cliente pode realizar varios alugueis, porem cada aluguel é feito por apenas um cliente (repare o uso da palavra “cada” que auxilia bastante na hora de classificar os relacionamento). Essa represntação e feita pelo DBDesigner, colorindo a metade chamada de ‘muitos’ de preto, ou seja, como cada cliente pode realizar muitos alugueis, o lado dos alugueis fica com a metade preta do losango, enquanto, como cada emprestimo e realizado por apenas um cliente, por isso a metade branca do losango aponta para a entidade cliente.

Porem essa representação é um pouco diferente da representação padrão onde teriamos algo assim:

Nessa imagem foram omitidos os atributos de cada entidade.

Como você pode ver ao inves de colorir os losangos indicando o tipo de relacionamento, em cada entidade é colocado um conjunto composto por dois caracteres entre virgulas, o primeiro caracter antes da virgula mostra o minimo do relacionamento, e o caracter apos a virgula o maximo do relacionamento.

No nosso exemplo, cada cliente pode fazer no minimo 1 e no maximo N (muitos) alugueis (1,N) e cada aluguel é realizado por no minimo 1 e no maximo 1 cliente (1,1). Essa metodologia mostra tanto o minimo quanto o maximo de um relacionamento, enquanto o DBDesigner só demonstra o maximo.

Alguns de voces podem estar pensando que um cliente pode ter um cadastro na locadora e nunca ter alugado nenhum filme, realmente isso pode acontecer, o que mudaria o minimo para 0 ao inves de 1, mas isso dependeria do modo como a locadora trabalha o cadastro de clientes, dado esse que deve ser levantado junto ao cliente em cada caso.

Apesar da metodologia padrão usar o minimo e o maximo, o mais importante num relacionamento é o seu maximo, que vai definir em qual das duas entidades será colocada a chave estrangeira, que faz a ligação entre as duas entidades no SGBD.

Mas antes de explicar as chaves estranjeiras vou mostrar todos os tipo de relacionamentos possiveis e uma explicação sobre eles:

Relacionamento 1-1

Esse relacionamento ocorre quando ambas as entidades se relacionam com maximo 1 para com a outra, não é um relacionamento muito usado já que na maioria dos casos quando uma entidade se relaciona dessa forma com a outra elas podem ser fundidas em apenas uma entidade, porem em alguns casos pode-se guardar infomaçoes opcionais sobre uma entidade em outra entidade, evitando assim que uma tabela de banco de dados tenha muitos atributos com valor nulo, caso todos esses valores opcionais fossem nulos não haveria nem a necessidade da criação de uma nova linha na entidade que porta esses dados opcionais

Relacionamento 1-N

É o tipo de relacionamento mais usado em banco de dados relacionais ocorrendo com o relacionamento maximo de uma tabela para outra é 1 e na ordem inversa é N, sendo esse o que foi usado no exemplo anterior e explicado atravez dele

Relacionamento N-N

Ocore quando ambas as entidades se relacionam com no maximo N para com a outra, nesse caso ocorre a criação de uma entidade fraca entre essas entidades para guardar o relacionamento entre essas duas atravez de suas chaves extrangeiras, no exemplo da locadora esse relacionamento pode ser encontrado no relacionamento entre alugueis e filmes representado abaixo:

Como se pode perceber, o DBDesigner transforma altomaticamente um Relacionamento N-N em dois relacionamento 1-N, a entidade fraca possui somente os ID`s das duas entidades com as quais se relaciona, porem pode ter outros atributos tambem.

No proximo topico iremos falar sobre Chaves Primarias e Estrangeiras e terminar nosso exemplo.

Como prometi no artigo anterior, vamos ao exemplo:

O primeiro passo para definir um banco de dados é encontrar no seu levantamento as entidades que o compões, no caso da locadora citada no artigo anterior elas são: cliente (pessoa fisica ou juridica), filmes, aluguel, e reserva. Em seguida definimos os atributos de cada entidade, os atributos são os dados que ficaram salvos sobre cada entidade.

Vamos usar o exemplo de clientes: os clientes tem nome, endereço, telefone e etc, porem no caso de clientes, alguns possuem CNPJ e outros CPF, por isso nesse momento é necessário o uso da especialização, como mostra a img abaixo:

Como vocês podem ver a simbologia utilizada pelo DBDesigner é um pouco diferente da teoria apresentada, mas em resumo, os atributos sao colocadas dentro da entidade, juntamente com o tipo de dados que sera utilizado para esse atributo, e o triangulo que representa uma especialização é representado por uma seta apontando da especialidade para sua entidade generalizadora.

Usando a metodologia padrão representariamos da seguinte forma:

Na proxima parte veremos como relacionar uma unidade com a outra, os casos de relacionamento e como identificar cada um.

Depois de um tempo sem escrever, envolvido com um projeto, vou voltar a falar sobre a documentação de projetos como havia prometido terminar a serie, só espero que esses tempinhos longos sem aparecer não se tornem frequentes.

Como proximo tema da serie temos o DER, ou Diagrama Entidade Relacionamento, velho conhecido dos administradores de banco de dados e de muitos desenvolvedores que utilizam bancos de dados relacionais em sua aplicações.

Em equipes e projetos grandes o o profissional responsavel pela construção de DER`s é o DBA porem em projetos pequenos e com poucos profissionais essa tarefa geralmente acaba nas mãos do programador.

Tambem existem varios softwares que facilitam o trabalho de diagramação do banco de dados, as imagens que vocês veram aqui são screenshots do DBDesigner que é o software de minha preferencia, outro software que tem recursos para tanto é o MS Visio, porem até mesmo softwares de imagens como Photoshop e Fireworks, e até mesmo o Paint podem ser usados, claro que para usar esse ultimo é necessario um pouco mais de, digamos, paciencia.

O DER é a representação grafica do MER, sendo representado por um conjunto muito pequeno de simbolos, o retangulo, representando a entidade, de onde saem pequenos traços com circulos em sua ponta para cada atributo dessa identidade, sendo que o circulo escuro representa a chave primaria dessa identidade, um losango, ligando atraves de retas duas entidades representando seu relacionamento e um triangulo representando as especializações de determinada entidade.

Apesar de parecer algo simples de desenhar, o DER consegue representar nesses poucos simbolos a estrutura completa de todo o banco de dados que será usada em determinada aplicação, mas para entender-mos melhor vou usar de exemplo um banco de dados simples para representar uma video locadora que loca filmes para clientes pessoa fisica e pessoa juridica armazenando nesse banco de dados as informações sobre reserva e alugueis realizados, mas isso você só vai ver no proximo post.

Voltando a falar sobre o modo como realizo as documentações dos meus projetos vou falar um pouco sobre AI

A AI é a documentação do projeto que define a estrutura das paginas de um projeto, assim como o fluxo de navegação de cada pagina, definindo a importancia dos elementos em cada pagina.

Inicialmente quando defino a Arquitetura da Informação de uma pagina começo por definir, quais serão as paginas que esse projeto deve conter já tendo pelo menos um noção do conteudo que o cliente irá enviar, o que cada pagina dessa deve conter, e qual é a hierarquia que existe entre essas paginas.

Vamos facilitar um pouco as coisas com um exmplo simples:
Supomos que em um determinado projeto, todas as paginas devem ter o menu, localizado de forma vertical ao lado esquero do conteudo e um rodapé, com as informações necessarias localizada no final da pagina, portanto já sabemos o que todas as paginas devem ter alem do conteudo e o posicionamento desses elementos na pagina.

Esse projeto, por exemplo, um site de uma agencia de desenvolvimento deve conter a home, uma pagina falando sobre a empresa, uma pagina para contato com a empresa e uma pagina com os projetos já realizados por essa agencia. Essa pagina de projetos deve ter internamente a ela paginas com um descritivo completo para cada projeto, portanto temos uma estrutura parecida com essa:

Home

Sobre

Projetos

Projeto 1

Projeto 2

Projeto 3

Contato

Sabemos tambem que a pagina home deve conter os ultimos projetos realizados por ordem decrescente de datas (do mais novo para o mais antigo) e que a pagina da empresa deve ter alem do texto apresentativo algumas fotos da agencia e ao final desse apresentação uma mensagem do presidente.

A pagina de contato deve ter um formulario para contato e alguns telefones para setores especificos da empresa logo a baixo.

Temos então um exemplo de arquitetura da informação de um projeto de desenvolvimento para web, com isso, alem de evitar duvidas sobre a futura localização das paginas e dos elementos na pagina frente ao cliente se torna bem mais facil a confecção do wireframe e do layout, que são os proximos itens da serie.