E também ministramos um mini-curso, tivemos muitos imprevistos nos laboratórios e portanto atrasou em 1 hora o início do mini-curso e no final tivemos o fim do mini-curso adiantado em 15 minutos, de fato tivemos apenas 45 minutos úteis. E por isso gostaríamos de deixar aqui registrado nossas desculpas aos participantes por esse imprevisto.

Mas acredito que pelo menos quem não sabia nada de web, saiu sabendo pelo menos um pouquinho. No mínimo sabendo o que precisa estudar para então correr atrás do conhecimento. E novamente os convidamos para participar do grupo afim de podermos nos ajudar a construir um grupo forte e representativo.

Para o mini-curso produzimos uma aplicação simples mostrando conceitos básicos de web e arquitetura em 3 camadas(MVC), que pode muito bem ser utilizado para produzirem suas próprias aplicações, código cujo nome é Guira, que significa pássaro em tupi-guarani, porque inicialmente era uma aplicação que iria acessar o twitter para twittar e consultar timelines e fazer pesquisas, algo meramente demonstrativo, porém tivemos um imprevisto de no local do evento não permitir o acesso ao twitter, e por ser um tanto burocrático a liberação mesmo que por poucas horas, decidimos fazer outra aplicação para não termos que depender de outras pessoas.

O código do Guira encontra-se no github:

• http://github.com/phpam/guira

Abaixo algumas fotos da participação do PHP-AM no FLISOL 2010:

As pessoas do grupo que estavam participando ativamente foram:

• Moacir Oliveira
• Rodrigo Rezende
• Daniel Martins
• Jônatas Pedraza

O FLISoL é um evento realizado em toda América Latina com o intuito de divulgar o Software Livre e mostrar alternativas livres a softwares proprietários, através de palestras, minicursos e installfest.

Em Manaus, o evento é organizado pelo Projeto Software Livre Amazonas, em conjunto com a Comunidade Software Livre, sendo patrocinado pela UniNorte e apoiado pelo Projeto Zagaia, SysV Soluções Open Source e Amazon Print.

Esse ano ocorre no dia 24 de abril.

O PHP-AM estará no evento ajudando na organização e realizando um encontro do grupo php-am com uma palestra e ministrando e um mini-curso(oficina php). Não deixe de participar.

Saiba mais no site do evento: http://am.softwarelivre.org/flisol

Membros Confirmados

Heitor Ferreira
Daniel Martins
Moacir de Oliveira
Luciano Antony
Marcelo Pinheiro
Jônatas Isvi
Rodrigo Rezende

Membros Presentes

Heitor Ferreira
Daniel Martins
Moacir de Oliveira
Jônatas Isvi
Rodrigo Rezende

Novos Membros

Daniel Bruno
Edgar

Pauta

1 – Status das atividades elaboradas na última reunião do grupo

2 – Primeiro projeto do grupo PHP-AM

Mais informações:

http://groups.google.com/group/php_am/browse_thread/thread/4f449c44f6742bc4

Participantes

* Moacir
* Heitor Ferreira (heitorFerreira)
* Jônatas Isvi (nona)
* Rodrigo Rezende (roudrik)
* Daniel Elias (vobiscum)

Pauta

PHP-AM (Organização do grupo e distribuição de tarefas)
Foram discutidos alguns tópicos relevantes para a organização do grupo, alguns deles:
* Blog
* Moderação da Lista de discussão
* Atividades em conjunto com o PHPBR
* Imprensa
A data de cumprimento das tarefas esta marcada para o mês de Dezembro.
A cada 15 dias haverá uma reunião do grupo para acertos das tarefas realizadas.
Locais e datas das reuniões serão informados pela equipe de imprensa.

Mais informações:

http://groups.google.com/group/php_am/browse_thread/thread/dcde527a94b2d72b

O PHP é sem dúvida a linguagem de programação mais bem documentada atualmente, já são mais de 10000 páginas de documentação disponíveis. E, para manter toda essa fonte de valiosa de dados, existem pessoas do mundo inteiro colaborando com o Manual e suas traduções, que é claro são open source. Neste post, vamos aprender como baixar e renderizar o Manual do PHP, primeiro passo para começar a contribuir com o Manual.

Todo o repositório do PHP foi migrado do CVS para o SVN recentemente, então, para baixar os fontes do manual, primeiramente certifique-se de ter uma cópia do Subversion instalada em sua máquina. Para baixar o manual faça:

$ svn co http://svn.php.net/repository/phpdoc/modules/doc-en phpdoc

Este comando criará a pasta phpdoc com os fontes do manual em inglês. Para baixar a documentação em português apenas substitua o doc-en por doc-pt_BR. A seguinte estrutura de diretórios será criada:

phpdoc/
- doc-base/
- en/

O diretório en/ possui o Manual propriamente dito, que é escrito no formato DocBook 5. Já o diretório doc-base possui vários scripts para manutenção do manual. Para configurar o manual faça o seguinte.

$ cd phpdoc/doc-base/
$ php configure.php

Se tudo der certo, ao final deste passo, o arquivo (gigantesco) .manual.xml deverá ser gerado. Este arquivo possui todo o manual formatado para que o PhD possa entrar em ação.

O PhD: [PH]P Based [D]ocBook Renderer é a ferramenta que renderiza o Manual nos diversos formatos disponíveis no php.net xhtml, pdf, chm etc. O próprio Manual online também é renderizado com o PhD. Como o PhD sempre utiliza a última versão do PHP, trate de instalar o PHP 5.3 se você anda meio desatualizado. Você também precisará do PEAR instalado em sua máquina. Para instalar o PhD faça:

$ pear install --alldeps doc.php.net/phd-beta

Com o PhD instalado já podemos renderizar o Manual, vamos testar o formato xhtml:

$ phd --docbook path/to/.manual.xml --format xhtml --package PHP --output manual

O PhD irá gerar os arquivos dentro do diretório manual/. O formato xhtml gerará o Manual em milhares de arquivos .html. Para testar faça:

$ firefox manual/php-chunked-xhtml/index.html

Agora você pode renderizar o Manual do PHP em sua máquina na hora que quiser \o/. O PhD possui outros formatos de saída como PDF e Manpages, para visualizar todos faça:

$ phd --list

Bem, esta é a configuração básica de qualquer contribuidor do Manual do PHP, se você quiser fazer alguma alteração no manual modifique os arquivos fonte no seu diretório phpdoc/en ou phpdoc/pt_BR e então rode novamente o configure.php e o PhD, e as suas modificações poderão ser vistas no seu browser.

O PhD também é utilizado para renderizar o Manual do PEAR e arquivos DocBook em geral. Qualquer dúvida com relação ao Manual ou o PhD envie um e-mail para a lista phpdoc@lists.php.net, ou acesse o canal #php.doc no EFNet. No próximo post darei mais dicas de como utilizar o PhD e contribuir com o Manual do PHP.

Abraço e até a próxima.

$ sudo pecl uninstall PDO_MYSQL
$ sudo pecl uninstall PDO

E depois reinstalar:

$ sudo pecl install PDO
$ sudo pecl install PDO_MYSQL

Um padrão de codificação é como se fosse um “ISO” de qualidade, ele torna a estrutura do código internacionalmente legível. Bom, assim todos esperam!

Neste artigo vou tratar alguns assuntos importantes que precisam ser levados em conta na hora de escrever códigos em PHP, é claro que nem tudo será abordado neste artigo. Muitos outros assuntos serão abordados em breve nos próximos posts que terão ligações com este artigo sobre codificação.

1 – Code Layout

1.1 – Indentação

É sempre bom usar 4 espaços para cada bloco de instrução.

O PHP não se baseia em indentação como delimitadores de blocos como o Python,
este assunto é até mesmo um pouco irrelevante, mas é um detalhe.
A questão de indentação no PHP é tornar o código mais legível para outros desenvolvedores
e até para você mesmo. Alguns desenvolvedores preferem usar tabs para o espaçamento do código,
mas é preferível usar apenas 4 espaços para cada bloco de instrução.

fig 1.1

1.2 – Cabeçalhos de instruções

É sempre bom usar 1 espaço entre a palavra chave e os parênteses para cabeçalhos
de instruções, não de funções ou métodos de classes.
O uso de apenas 1 espaço dentro dos parênteses também é aceito.

fig 1.2

e assim por diante.

1.3 – Loops aninhados

É a única ocasião em que variáveis com tamanho igual a 1 são permitidas e até mesmo encorajadas.
Sempre use $i como nome da variável do primeiro índice do laço mais externo, logo após você deve usar as letras que seguem na ordem alfabética.
Tente não usar a letra l “L” na forma minúscula porque ela parece com o algarismo 1.

Fig 1.3

1.4 – Incluindo chaves

Chaves devem ser sempre incluídas quando estivermos usando blocos if, for, while e etc. Não há
exceções para esta regra, mesmo que as chaves possam ser omitidas.
A chave de abertura deve ser posta uma linha depois da instrução e a chave de fechamento deve ser alinhada com a chave de abertura.
Esquecendo esta regra podemos tornar o código mais difícil de manter no futuro e ainda corremos
riscos de aperecerem bugs muito difíceis de serem achados.

Fig 1.4

1.5 – Uso de espaçamentos

A melhor receita é um exemplo!

No exemplo a seguir será apresentado a forma correta acompanhada da forma incorreta.

Fig 1.5

1.6 – Expressões

Sempre use parênteses para suprimir ambiguidades.
Usando parênteses força-se uma ordem de avaliação, isto ajuda a poupar tempo de análise.
da precedência de operadores.
As vezes eliminar o operador binário not (!) torna a expressão mais clara de se entender.
Mantenha cada linha simples.

2 – Convenções de Nomes

2.1 – Nomes de variáveis

Nomes de variáveis devem sempre começar com letras minúsculas e com as palavras separadas por
underline “_”.

Os nomes das variáveis no PHP devem ser descritivos e concisos, mantendo sempre um tamanho
de 15 caracteres, isto não é uma regra mas sempre que possível é bom seguir o conselho para
uma questão de claridade do código.

Fig 2.1

2.2 – Nomes de constantes

Nomes de constantes devem conter todos os caracteres em maiúsculo e separando as palavras com
underline “_”, devem seguir as mesmas regras das variáveis. As constantes também podem ser declaradas com a função define($nome, $valor), sendo que nesta função há um terceiro argumento booleano que torna verdadeira a leitura da constante de várias formas, mas isso não é uma boa prática.

leia: http://php.net/define

Fig 2.2

2.3 – Nomes de funções

Devem seguir as mesmas regras das variáveis e sempre que possível atribuí-la a um verbo, como;

Fig 2.3

através dos nomes dados as funções é fácil saber o que ela executa ou pode executar.

2.4 – Argumentos de funções

Argumentos de funções são variáveis de contexto local, logo todas as regras que valem para as variáveis valem aqui também.
Se a função possui mais de um argumento eles precisam estar separados por um espaço, tanto na chamada da função como na sua construção. Os nomes de argumentos também ajudam a definir o propósito da função.

Fig 2.4

2.5 – Classes

Nomes de classes precisam estar no estilo Camel Case, e de preferência estar definida com apenas uma palavra se for conveniente e quando possível.

Fig 2.5

2.6 – Métodos de classes

Métodos de classes precisam estar no estilo Camel Case, mas pode-se usar o estilo de funções sem nenhum problema.
Mas uma condição deve ser satisfeita, se você começar a escrever métodos de classes com um tipo de estilo então termine com este, por favor não faça uma salada!

Fig 2.6

3 – Strings

Strings em PHP podem ser usadas com aspas simples ” ou aspas duplas “”.
A diferença entre elas é que o parser irá usar interpolação de variável ou usará os caracteres de escapamento em uma string com aspas duplas, e em uma string com aspas simples todo o valor é mantido como está, então;

Fig 3

enquanto que atribuindo ao print o mesmo valor mas dentro de aspas simples, isso irá renderizar o mesmo valor sem interpolação.

O que é preciso conscientizar-se desta regra, é que sempre que você for atribuir um valor do tipo string a uma variável e este valor não possuir nenhuma interpolação ou caracteres de escape atribua com aspas simples, isso acaba aliviando o parser e consequentemente ajuda na performance.

Conclusão

Muitas abordagens deste artigo não significam que você deva seguí-las como uma religião, a questão aplicada aqui é global. Você é o desenvolvedor, sua cabeça é o seu guia.

Mas como experiência a minha dica é; “faça o possível para seguí-las”. Isso vale até pra ajudá-lo a entender o código que você mesmo escreveu. Um código bem feito tem mais chances de ser aceito pela comunidade global de desenvolvedores.

Alguns assuntos como; Exceções e Documentação, serão abordados em um outro post mas que tem uma ligação fortíssima com este artigo.

Até um outro post!

Parabenizo a todos os participantes da lista de discussão do PHP-AM pela iniciativa de construir um site com conteúdo sobre a linguagem PHP, essa é uma nova empreitada e chamamos a nós a responsabilidade de gerar conteúdo técnico-científico que satisfaçam as necessidades de todas as categorias, de iniciantes à avançados.

Ressalvas

A comunidade já conta com alguns escritores que estão se esforçando ao máximo para gerar conteúdo e tráfego para o site. Mas é preciso que os membros que já possuem conhecimento suficiente na linguagem também se tornem escritores para que o site tenha um leque moderado de posts. Contudo, é preciso lembra que toda a contribuição é voluntária e não há alguma política que obriga você, membro da comunidade, a cooperar com o desenvolvimento do PHP-AM. Mas toda a contribuição é bem-vinda e respeitada pelos participantes.

Toda a iniciativa precisa passar por uma avaliação dos membros mais fluentes da comunidade para que nada de desagradável ou irrelevante venha a ser exposto no site.

O site da comunidade não é apenas para gerar posts, discussões ou reuniões mas também é possível a iniciativa de projetos para o desenvolvimento da linguagem, como;

• traduções
• criações de ferramentas
• correções de bugs
• criações de novas features
• dentre outros.

A idéia inicial de ser uma comunidade diferente, continua. Mas para que isso seja possível todos nós precisamos de boas idéias e de um grupo consistente de desenvolvedores. E você que está lendo este post e deseja ou já é participante do grupo, com certeza você é um forte candidato para participar desses projetos.

Então é PHP na cabeça, espírito de equipe e nada de bugs hein…

Nona

No andar da carruagem vamos personalizar mais o design do site e publicar conteúdo relevante de PHP além de mencionar empregos locais para programadores PHP.

Caso queira entrar em contato com a comunidade, sinta-se a vontade para se inscrever na lista de dicussão.