XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

ABAP (SAP)
(sap programador abap) – O usuario pede uma coisa simples, mate o dragão com a espada e case com a princesa. O funcional entende e especifica, mate o dragão com a princesa e case com a espada. O ABAP desenvolve, mate a princesa com o dragão e joga a espada fora ja que nao serve para nada. No fim a princesa casa com a espada e o dragão mata o funcional e o usuario. Assim acaba o trampo do ABAP. (sap analista funcional) – Olha só o que o ABAP faria, muito simples. Ficaria espantado com a princesa, chamaria o funcional para pega-la. O funcional casa-se com a princesa e o abap casa-se com o Dragão e engole a espada.

Java
Chega, encontra o dragão. Desenvolve um framework para aniquilamento de dragões em múltiplas camadas. Escreve vários artigos sobre o framework, mas não mata o dragão.

.NET
Chega, olha a idéia do Javanês e a copia, tenta matar o dragão, mas é comido pelo réptil.

Javascript
Desenvolve uma funcao para encontrar o dragao. Por uma incompatibilidade de visualização vê a princesa ora como um metrossexual ora como uma drag queen. Desiste de matar o dragão e vai embora sem a princesa.

ASP
Os componentes necessários para levantar a espada são proprietários e caros. Outros tantos componentes proprietários para achar a localização do dragão, e mais outros tantos a localização da princesa. Chama então seu amigo programador de PHP.

C
Chega, olha para o dragão com olhar de desprezo, puxa seu canivete, degola o dragão. Encontra a princesa, mas a ignora para ver os últimos checkins no cvs do kernel do linux.

C++
Cria um canivete básico e vai juntando funcionalidades até ter uma espada complexa que apenas ele consegue entender … Mata o dragão, mas trava no meio da ponte por causa dos memory leaks.

COBOL
Chega, olha o dragão, pensa que tá velho demais para conseguir matar um bicho daquele tamanho e pegar a princesa e, então, vai embora de volta ao seu mundinho.

ADVPL
O programador tenta de todas as formas eliminar o dragão, porém, nunca obtém sucesso, ja que por ser uma pseudo-linguagem de programação (uma linguagem derivada de outra linguagem) ele se tornou o próprio dragão.

Pascal
Se prepara durante 10 anos para criar um sistema de aniquilamento de dragão… Chegando lá descobre que o programa só aceita lagartixas como entrada.

Python
Em poucas linhas encontra e mata o dragao com a espada. Usa algum framework recem lançado para pegar a princesa, que foge de medo.

LaTeX
Percebe que matar o dragão não leva a nada e prepara um livro enorme sobre a historia do dragão com a princesa.

VB
Monta uma arma de destruição de dragões a partir de vários componentes, parte pro pau pra cima do dragão e, na hora H, descobre que a espada só funciona durante noites chuvosas…

PL/SQL
Coleta dados de outros matadores de dragão, cria tabelas com N relacionamentos de complexidade ternária, dados em 3 dimensões, OLAP, demora 15 anos para processar a informação. Enquanto isso a princesa virou lésbica.

PHP
Pesquisa bancos de scripts e acha as classes de construção de espada, manuseio da espada, localização da princesa e dragão. Remenda tudo e coloca umas firúlas próprias. Mata o dragão e casa com a princesa. Como tudo foi feito com gambiarras, o dragão um dia vai ressuscitar e comer os dois.

Ruby
Chega com uma p*t* fama, falando que é o melhor faz tudo, quando vai enfrentar o dragão mostra um videozinho dele matando um dragão … O dragão come ele de tédio.

Smalltalk
Chega, analisa o dragão e a princesa, vira as costas e vai embora, pois eles são muito inferiores.

ASSEMBLY
Acha que está fazendo o mais certo e enxuto, porém troca um A por um D, mata a princesa e transa com o dragão.

Shell
Cria uma arma poderosa para matar os dragões, mas na hora H, não se lembra como usá-la.

Shell (2)
O cara chega no dragão com um script de 2 linhas que mata, corta, stripa, pica em pedacinhos e empalha o bicho, mas na hora que ele roda, o script aumenta, engorda, enfurece e coloca álcool no fogo do dragão.

Fortran
Chega, desenvolve uma solução com 45000 linhas de código, mata o dragão e vai ao encontro da princesa … mas esta o chama de tiuzinho e sai correndo atrás do programador java que era elegante e ficou rico.

FOX PRO
Desenvolve um sistema para matar o dragão, por fora é bonitinho e funciona, mas por dentro está tudo remendado. Quando ele vai executar o aniquilador de dragões lembra que esqueceu de indexar os DBF’s.

CLIPPER
Monta uma rotina que carrega um array de codeblocks para insultar o dragão, cantar a princesa, carregar a espada para memória, moer o dragão, limpar a sujeira, lascar leite condensado com morangos na princesa gostosa, transar com a princesa, tomar banho, ligar o carro, colocar gasolina e voltar pra casa. Na hora de rodar recebe um “Bound Error: Array Access” e o dragão come ele com farinha.

Caso algum leitor deste blog queira acrescentar ou indicar uma linguagem de programação por favor entre em contato.

Via: De Proprio Punho

E se você já conhece o framework, deve saber que há algum tempo o Sergio Jardim deu o pontapé no esforço da tradução do Guia do Usuário.

Com a movimentação a favor da tradução do user guide lá no fórum oficial, surgiu também o domínio www.codeigniter.com.br, e com ele a lista de discussão brasileira sobre o framework.

E essa lista de discussão é recomendada pra você que já usa ou pretende usar o framework. Sou um dos moderadores, e estamos a todo vapor conhecendo bons profissionais e empresas que já fazem uso desta poderosa ferramenta.

Depois de alguns bugs corrigidos, agora está funcionando perfeitamente. Você tem duas opções de uso:

PHP – Os dados são buscados e montados na página durante o processamento da mesma.
Ajax – Os dados do comentarista serão buscados após o carregamento completo da página. Diferente do que alguns acham, neste método o uso da banda é o mesmo, mas o processamento passa mais para o lado cliente, já que o JavaScript é executado no navegador.

Eu escolhi a opção PHP, já que a demanda dos meus sites não é tão grande assim. Essa opção é boa também pois exibe os dados mesmo se o usuário tiver desabilitado a opção de JavaScripts no navegador.

Você pode conferir o plugin funcionando em alguns artigos deste blog, ou escrever um comentário neste artigo e ver seu perfil do BlogBlogs aparecendo nele.

Quando descoberto, esse código começou a aparecer em sociais bookmarks como o Digg e imediatamente os “protetores” dessa indústria foram lá como verdadeiros anti-agentes americanos e proibiram o site de divulgar esse código sob qualquer pretexto. A reação imediata foi um bombardeamento desse código por incontáveis blogs e sites e sua publicação no Digg e outros parecidos, como afronta à censura que essas (des)organizações gostam de promover.

Chegou um ponto onde o fundador do Digg chutou o balde e declarou:

We had to decide whether to remove stories containing a single code based on a cease and desist declaration. We had to make a call, and in our desire to avoid a scenario where Digg would be interrupted or shut down, we decided to comply and remove the stories with the code.

But now, after seeing hundreds of stories and reading thousands of comments, you’ve made it clear. You’d rather see Digg go down fighting than bow down to a bigger company. We hear you, and effective immediately we won’t delete stories or comments containing the code and will deal with whatever the consequences might be.

If we lose, then what the hell, at least we died trying.

Uma prova que a Internet tem que ser livre, e como os consumidores demonstram à uma indústria atrasada que insiste em não aprender que é assim que tem que ser.

Ela basicamente tem a função de detectar todos os idiomas suportados pelo browser do usuário e escolher a que está na melhor posição, de acordo com as linguagens suportadas pelo site visitado.

Foi escrita em PHP 5 OO, e pode ser usado livremente em qualquer site ou sistema web – bastando respeitar a licença GPL.

Leia mais detalhes e exemplos de uso na página do projeto ou direto no PHP Classes.

Ah, se você for usuário cadastrado no PHP Classes, pode aproveitar e votar nela no User Ratings.

O Fernando Dantas, que já trabalhou comigo no passado, falou sobre o Windows Vista. A abordagem foi superficial e muito do que foi apresentado já era de conhecimento de quem está sempre acompanhando notícias sobre tecnologia. Teve a questão do live search no sistema, que busca programas, documentos, etc. Foi falado sobre a criptografia direto no HD, que só tá disponível na versão Ultimate – mais cara. Foi citada a questão das abas no IE7 que foi herdada do Opera e do Firefox – acho que poderia ter falado do suporte a feeds nesse novo IE, além das abas.

Também foi apresentado o Aero que melhora a apresentação visual do sistema e que só roda em máquinas com boa placa de vídeo – eu uso o Beryl no Ubuntu e tenho efeitos visuais muito mais interessantes no meu notebook, sem ter que pagar nada pra usar um sistema novo em máquina de ponta.

Outros palestrantes falaram do uso do DotNet no mercado e a parte que mais me chamou a atenção foi a apresentação do ASP.Net 2.0. Já trabalhei com ASP quando não era nem .Net (coloque anos aí), e quando conheci o PHP (na versão 3, na época) foi muito interessante. A linguagem é fácil, poderosa e está sempre em evolução. O cara lá falou que já trabalhou com PHP mas quando conheceu .Net descobriu uma linguagem de ponta com recursos de ponta…

Não vou entrar aqui na eterna briga das linguagens, mas algumas coisas na apresentação me deixaram com a sensação de sujeira e dependência: a demonstração com o Visual Studio 2005 realmente provou que a ferramenta é poderosa e auxilia bastante o desenvolvimento – bastou clicar duas vezes num button e era possível codificar a rotina que rodaria at server no seu evento. Mas quem me garante que essa mesma ferramenta trabalha com qualidade de código? Quem já usou o Dreamweaver sabe o quão dependente o usuário se torna, devido ao código sujo e porco que ele gera – é mais fácil abrir no modo design e trabalhar ali com os panels do Dreamweaver, a colocar a mão no código e ficar perdido! A mesma sensação eu tive quando vi o que o Visual Studio estava fazendo. E outra, ou você conhece bem uma ou mais linguagens e como funciona a arquitetura de ambientes web, ou você se torna dependente de uma ferramenta pro resto da vida.

A última apresentação foi sobre Arquitetura de Software, e ainda bem que não foi divulgado nenhum produto Microsoft, para não vincular a idéia à marca, senão eu seria obrigado a argumentar aqui que com PHP também se desenvolve em 3 camadas, por exemplo, além de contar com excelentes frameworks como o Code Igniter ou o da própria Zend.

Bom, de qualquer forma, no final ainda ganhei um brinde da MS. Parabéns ao BrasilDotNet por ter a coragem de entrar em campo e sair na frente de grupos como o PHP-DF que há meses planeja, planeja e aparentemente não sai do lugar. Preferia muito que a noite tivesse sido do grupo de desenvolvedores PHP do DF, divulgando a linguagem para aqueles universitários e mostrando que sistemas de qualidade podem sim ser feitos com tecnologias e linguagens gratuitas, fáceis e poderosas.

E que a informação seja cada vez mais aberta a todos!!!

Esta terceira parte apresenta a forma como as informações (acerca das ferramentas e demais elementos utilizados) são pesquisadas. Também é mensurada a facilidade em encontrar tais informações, bem como a qualidade das mesmas. Por fim, é apresentado o levantamento da necessidade de um Sistema Web para divulgação destas informações e ferramentas e, ainda, os serviços necessários a este sistema.

Parte 3

Busca por conhecimentos: No que se refere à pesquisa para aperfeiçoamentos, ou busca de novos conhecimentos, 65% declarou fazê-la diariamente. 21% faz mais de uma vez por semana, e 6% realiza pesquisas uma vez por semana.

Tipos de informações: As informações mais procuradas pelos profissionais (20% deles) são tutoriais, apostilas e cursos. 18% participam de forum, listas de discussões ou chats e outros 18% fazem downloads de ferramentas. 14% pesquisa documentações de produtos e 13% procuram componentes com código aberto e pronto para reuso.

Área de interesse das informações: As linguagens de programação (11%), bancos de dados (10%) e aplicações web (10%) provocam bastante interesse nos desenvolvedores. Em seguida vem a análise e projeto de sistemas (teoria) com 8% e ambientes de desenvolvimento integrado (IDE) com 7%.

Meio de acesso à informação: cerca de 20% utiliza sites de busca na internet, seguidos pelos foruns (15%) e listas de discussões (14%).

Sites de busca: o mais usado pelos profissionais é disparado o Google, com 94% dos usuários de site de busca. Em seguida vem o Yahoo! (1%) e o Cadê? (0,95%).

Avaliação da facilidade de busca: 65% acha muito fácil pesquisar e encontrar conteúdo de interesse na Internet. 23% acha muito fácil e 10% apenas ainda acha difícil fazer buscas na internet.

Qualidade da informação encontrada: 68% acha que a informação encontrada é completa ou satisfatória. 26% acha insuficiente ou incompleta, e 4% acha que o conteúdo encontrado é excelente.

Este é o cenário brasileiro atual, no campo de desenvolvimento de software.

Se você tem interesse em participar desta pesquisa, ainda dá tempo. Fui informado pela equipe do Guia do Programador que a pesquisa vai até o dia 20/03/2007. Então corra, participe e ajude a termos números cada vez mais sólidos sobre nossa área de atuação.

Confira a série completa:

• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 1
• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 2
• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 3

Parte 2

Quantidade de sistemas implementados: A maioria dos entrevistados (35%) já implementou de 2 a 5 sistemas durante a carreira. Em segundo lugar está o score de mais de 10 sistemas, para 23% dos respondentes. Empatados em terceiro estão os que já implementaram de 6 a 10 sistemas e os que não implementaram nenhum.

Metodologia de Engenharia de Software e Processo de Software: Maioria absoluta utiliza programação orientada a objetos, representando 66% dos pesquisados. A programação estruturada representa 13%, em segundo lugar. Quase 40% dos profissionais não utilizam um processo de software, 13% utilizam o método cascata e 12% o RUP (Rational Unified Process).

Plataforma Computacional, de Desenvolvimento e Sistema Operacional: 88% dos desenvolvedores trabalham com PC e 11% com Unix, sendo um total de 80% no Windows e 16% no Linux. Grande parte do desenvolvimento de software no Brasil está apoiada no Java. .NET representa 10% e outras ou nenhuma acumulam o restante.

Linguagens de Programação: Java mais uma vez sai na frente com quase 20% dos programadores brasileiros, seguida pelo PHP com quase 15%. Em seguida foram citados Delphi / Object Pascal, C, C++ e PL/SQL, respectivamente. C#, Java ME (J2ME), Pascal e (Visual) Basic estão com os mesmos 4%, e as demais linguagens ainda não são representativas.

Tecnologias Web: No ambiente web, 12% declarou dominar HTML e 11% Javascript. PHP e XML vêm em terceiro com 8% cada, e AJAX e JSP em quarto com 6% cada.

Ambiente de Desenvolvimento Integrado (IDE): O Eclipse domina sendo usado por 30% dos desenvolvedores. O Borland Delphi em segundo para 15% e o NetBeans em terceiro com 9%, seguido pelo Microsoft Visual Studio. 13% declarou não usar nenhum ambiente de desenvolvimento.

Banco de Dados: O MySQL é usado por 36% das empresas, seguido pelo Microsoft SQL Server (16%), Oracle 10g e PostgreSQL (11%). O Firebird é usado em 8% dos casos.

Servidor de Aplicação / Web: O Apache HTTP Server é lider seguido pelo Apache Tomcat, ambos somando quase 60% dos servidores de aplicação/web. Em terceiro lugar está o JBoss com 8%.

Browser (navegador): O Firefox é usado por 60% dos desenvolvedores, seguido pelo Internet Explorer que totaliza 33%. Outros navegadores não somam de forma significativa.

Em breve publicarei a terceira parte dos resultados, que apresenta a forma como as informações (acerca das ferramentas e demais elementos utilizados) são pesquisadas. Também é mensurada a facilidade em encontrar tais informações, bem como a qualidade das mesmas. Por fim, é apresentado o levantamento da necessidade de um Sistema Web para divulgação destas informações e ferramentas e, ainda, os serviços necessários a este sistema.

Confira a série completa:

• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 1
• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 2
• Resultado da pesquisa sobre desenvolvimento de software no Brasil – Parte 3

Hoje foi anunciado o lançamento do site oficial do grupo de desenvolvedores PHP do Distrito Federal.

Há muito que Brasília vem aguardando esse anúncio, e finalmente após vários meses de discussões e planejamento entre os coordenadores e os membros envolvidos, foi dado início ao projeto. A proposta é que se organize eventos periódicos para expandir o uso e aceitação do PHP no mercado de desenvolvimento local.

Se você é do DF e está interessado, conheça o site do grupo e assine a lista de discussões php-brasilia.