Uma das melhores características do Firefox é a possibilidade instalar complementos, que auxiliam em várias tarefas.
Para procurar mais complementos consulte o site do Mozilla.

Separei alguns complementos mais com o perfil de webdeveloper.

• Web Developer – Ótima ferramenta para desenvolver e debugar layout.
• Html Validator – Valida o HTML.
• Firebug – Indispensável. Com ele você tem todo o controle sobre o HTML, CSS, JavaScript além de outras funcionalidades.
• Dicionário pt-br – Dicionário de português para o Firefox.
• ShowIP – Exibe o IP da máquina.
• FireFTP – Gerenciador FTP.
• Library Detector – Detecta a biblioteca JS utilizada no site.
• BBComposer – Ferramenta WYSIWYG para edição de textarea (ótimo para wiki e blogs).

Temos diversas variações de leite, leite de soja, semi-desnatado, desnatado, de cabra etc. cada um tem o seu preferido, e temos muitas fábricas que produzem os mesmos tipos de leite.
Para algumas fábricas de leite, o importante é ter consumidores, não importando o jeito que ela produz leite. Pensando assim, estas fábricas andaram alterando a composição do leite, colocando cal e água oxigenada para diminuir os seus custos. Oficialmente não morreu ninguém por causa disto, e o consumidor tomou o leite e nem percebeu a alteração, pois o que importa é que ele consumiu e gostou.
Pagamos qualquer preço para tomar o leite de nossa preferência, mas não compramos leite de uma marca supostamente alterada, mesmo não percebendo a alteração no gosto.
Não estamos questionando qual é o leite mais gostoso, e sim questionando como ele é feito, ter a certeza que os componentes e o método de fabricação não irão causar danos a saúde ao longo do tempo.
Para a fabricação de leite existem normas e métodos para garantir qualidade, dentre outros fatores. Em informática encontramos a mesma situação, principalmente que na maioria das vezes o consumidor entende mais de leite do que de informática.
Quando a parte profissional, nega-se a aceitar em sempre estar melhorando a qualidade do produto, e o que realmente importa é o cliente achar que “o leite dele não esta alterado” e pagar bem por isso, estará contribuindo para “a marca” (a linguagem PHP no caso) venha a sofrer boicotes, quando a mesma participar de uma pré seleção em um projeto de grande porte.
Se o PHP ficar circulando apenas em pequenas empresas e projetos pequenos, nunca um empresário terá condições de pagar salários maiores aos seus programadores. Uma solução seria trabalhar como autônomo para tentar ganhar mais, isto só é bom para o programador, porque o PHP ainda continuará em pequenos projetos.

A intenção não é ofender nem abrir confronto contra programadores PHP (pois sou um) e muito menos de outras linguagens, mas sim em refletirmos o porque que o PHP vem sendo “marginalizado”.

Deixar de aceitar propostas de emprego de programador PHP mal remuneradas e/ou mudar de linguagem é uma ótima saída, mas não resolve, pode-se ganhar mais, mas usar uma ótima linguagem não garante que você seja um ótimo programador.

O PHP virou linguagem de websites rápidos baratos e algumas vezes mal planejados, devido as próprias limitações da linguagem e falta de conhecimento de técnicas de programação e o baixo custo de manter um servidor LAMP.

“Mentira!! Eu tenho um sistema em PHP de grande porte que atende mais de XXX usuários por todo o mundo.”
R: Sim, temos bons programadores em PHP e grandes projetos isto não há dúvidas.

Mas porque então que o PHP esta sendo tratado como “linguagem de estagiário”?
Vamos antes para algumas perguntas:

Quantos programadores de PHP são certificados?
Quantos programadores de PHP realmente sabem OO, Padrões de Projetos, Teste Unitário, Controle de Versão e programam de maneira modular?
Quantos programadores de PHP usam Programação Ágil ou usam algum framework para facilitar o desenvolvimento?
Quantos programadores de PHP pensam em qualidade, em sempre estar melhorando suas técnicas, em um aprendizado contínuo?

Alguém vai pensar:

“Não sou estagiário, mas eu não sei tudo isso, nem penso assim, e ganho uns R$3000,00, não preciso saber tudo isso!”
R: Errado, precisa sim. Se você ganha mais que R$1500,00 ao menos tem que saber OO e alguns Padrões de Projeto, pois é o mínimo para se tirar uma certificação da Zend (PHP 5).

Nunca fique limitado em uma linguagem (principalmente PHP), estude outras linguagens para melhorar os seus conhecimentos.
O PHP possui limitações sim, e temos que aprender a lidar com elas, e uma das alternativas mais claras é aprender outras linguagens e suas técnicas, perceber onde o PHP possa ter uma performance eficiente barata e de qualidade. Saber onde não deve ser usado o PHP garante a integridade da linguagem e evita aborrecimentos.
Quanto mais aprender JAVA, .NET, Python, melhor vai ficar o seu código em PHP.

Antes de discutir com programadores de outras linguagens e de questionar o salário de programador PHP, pense se o seu preparo esta equivalente, analise os seus conhecimentos, defeitos, qualidades, e técnicas para garantir que terá chance de não só estar certo mas, em também aprender com os outros.

A Zend esta investindo em framework e certificação baseado em PHP 5, assim como a adoção de muitos conceitos de programação OO, onde a linguagem sempre foi deficiente. Cabe a cada programador PHP se aprimorar e começar a usar recursos avançados do PHP 5 e conceitos adquiridos de outras linguagens.

Temos que mostrar que com o PHP podemos sim, fazer excelentes sistemas profissionais com a mesma qualidade e eficiência de outras linguagens, para isso, cabe a cada programador PHP ter a consciência em se aprimorar.

Alexandre F. Martins (ZED)

Princí­pios do Manifesto Ágil

• Indiví­duos e interações – mais importantes que processos e ferramentas.
• Software funcionando – mais importante do que documentação completa e detalhada.
• Colaboração com o cliente – mais importante do que negociação de contratos.
• Adaptação a mudanças – mais importante do que seguir o plano inicial.

Evento ocorrido em 2001
WebSite: http://www.agilemanifesto.org

Extreme Protramming (XP)

Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princí­pios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

Valores

• Comunicação – Reuniões presencias.
• Coragem – Não limitar as mudanças e confiar nos mecanismos, como desenvolvimento orientado a testes, programação em par e integração contínua.
• Feedback – Trabalhar mais perto do cliente, detecção e correção precoce de falhas.
• Respeito – Sinergia entre a equipe, saber respeitar as opiniões.
• Simplicidade – Primeiramente fazer apenas o necessário.

Princí­pios

• Auto-semelhança – Reaproveitamento de soluções, códigos e métodos, mesmo em escalas menores.
• Benefí­cio Mútuo – Benefí­cios como programação em par, e minimo de erros no funcionamento do programa beneficiam a todos.
• Diversidade – Opiniões de profissionais de diferentes áreas contribuem para uma solução rica.
• Economia – Implementar primeiro funcionalidades que puderem gerar maior retorno financeiro.
• Falha – Testar ambas as falhas de idéias conflitantes para resolver o mesmo problema, botar em prática.
• Fluidez – Estabelecer um fluxo contí­nuo estabelecendo etapas bem definidas, repetindo cada uma gradualmente.
• Humanismo – Respeitar a natureza dos desenvolvedores, explorar melhor de maneiras diferentes.
• Melhoria – Melhoria contínua, enquanto mais aprendemos mais mais somos capazes de melhorar.
• Oportunidade – Enxergar problemas como oportunidades de aprendizado e mudanças proveitosas.
• Passos de Bebê – Desenvolver o sistema em pequenas partes.
• Qualidade – Aumentar a qualidade resulta em entregas mais rápidas.
• Redundância – Fazer testes redundantes somente quando os mesmos forem úteis.
• Reflexão – Pausas informais em conjunto provem reflexões das ações.
• Responsabilidade Aceita – Responsabilidade não pode ser atribuí­da, ela só pode ser aceita.

Papéis

• Analistas de Teste – Ajudam clientes e desenvolvedores a escrever testes para as histórias, antes mesmo que elas sejam implementadas.
• Arquitetos – Ajudam os desenvolvedores no dia-a-dia através da programação em par, refatoração e a arquitetura do ambiente.
• Designers de Interação – Trabalham próximo aos clientes, os ajudam a escrever histórias e escolher metáforas consistentes para o projeto.
• Executivos – Ajudam na definição do escopo do projeto, asseguram que as histórias estejam alinhadas.
• Gerentes de Projeto – Agem como facilitadores no fluxo de comunicação do projeto, motivam a equipe e removem obstáculos.
• Gerentes de Produto – Procuram definir histórias que ajudem o produto a tomar um corpo coerente e harmônico, reduzir o escopo quando a equipe está atrasada.
• Programadores – Trabalham em pares implementando histórias, são responsáveis por criar testes automatizados e da refatoração.
• Recursos Humanos – Selecionam indiví­duos que saibam interagir socialmente com naturalidade.
• Redatores Técnicos – Asseguram que a documentação evolua de forma iterativa.
• Usuários – Ajudam a escrever e selecionar histórias e tomam decisões relativas ao domí­nio do negócio durante o desenvolvimento.

Práticas Primárias

• Ambiente Informativo – O ambiente deve conter todos os elementos que ajutem a equipe a relembrar suas tarefas, como quadro branco, flip chart, gráficos, etc.
• Build de Dez Minutos – Usar testes automatizados.
• Ciclo Semanal – Reunião semanal que recebe o nome de Jogo do Planejamento, aonde clientes e desenvolvedores decidem as funcionalidades e prioridades.
• Ciclo Trimestral – A cada trimestre a equipe se reúne com o cliente para definir as próximas etapas e refletir sobre as passadas.
• Desenvolvimento Orientado a Testes – Antecipa a identificação e correção de falhas durante o desenvolvimento.
• Design Incremental – Criar soluções simples e por demanda, de acordo com as nescessidades do cliente.
• Equipe Integral – Cliente com maior disponibilidades, conversas presenciais melhoram o feedback.
• Folga – Ajuda a equipe a acomodar imprevistos, aumentando a motivação para cumprir promessas.
• Histórias – São contadas pelos clientes aos desenvolvedores, servem de resumo e delegam prioridades.
• Integração Contí­nua – Isar um repositório para o projeto mantendo a base de código consistente.
• Programação em Par – Dois programadores por micro, diminuem os erros, aumenta o rendimento e códigos mais elaborados.
• Sentar-se Junto – Mesmo ambiente para todos os desenvolvedores mantendo um contato presencial.
• Trabalho Energizado – Trabalhar de forma inteligente, respeitando o desgaste do desenvolvedor.

Práticas Corolárias

• Análise da Raiz do Problema – Forçar o teste nos defeitos e não apenas os casos de sucesso.
• Base de Código Unificada – Reduzir ramificações de versões, colocando as diferenças como configurações.
• Código Coletivo – Com a rotatividade dos programadores ocorre um refatoramento com mais qualidade.
• Código e Testes – Quanto melhor o design incremental menos decisões precisam ser tomadas com antecedência.
• Continuidade da Equipe – Manter equipes inegradas melhorando os valores dos relacionamentos.
• Contrato de Escopo Negociável – Contratos de curta duração, podendo ser renovados ou cancelados em qualquer etapa.
• Envolvimento do Cliente Real – Trazer usuários para testar o sistema em desenvolvimento.
• Equipes que Encolhem – Trabalhar para que a equipe diminua, sempre deixar um elemento com menos trabalho.
• Implantação Diária – Atualizar o sistema com mais frequencia, remover barreiras que impeçam estas atualizações.
• Implantação Incremental – Fazer mudanças gradualmente e manter ao mesmo tempo o sistema antigo e o novo.
• Pagar Por Uso – Cobrar do cliente por releases menores e mais frequentes, com o maximo de funcionalidades.

Outras Práticas

• Reunião em Pé – Reuniões diarias em pé, aonde todos os desenvolvedores contam o que fizeram e irão fazer.
• Refatoração – Alterações constantes, limpeza , clareza e aprimoramento do código.
• Metáfora – São elementos do cotidiano que são inseridos nos sistemas.

Referências

Resumo do site www.improveit.com.br/xp/

Projeto C3 (Chrysler) – Kent Beck, Ward Cunningham and Ron Jeffries (1996) www.xprogramming.org