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.

- Na verdade isso responde muita coisa. Eu sempre tive o pressentimento que algo grande e sinistro acontecia no mundo.
- Não. Isso é chamado de paranóia. Todos no universo sofrem disso.
- Talvez eu esteja velho e cansado, mas as chances de sabermos o que acontece de verdade é tão remota que o melhor a fazer é seguir em frente e se ocupar com algo. Prefiro ficar contente do que ficar me remoendo.
- E você é feliz?
- Ah… não. Esse é o problema.

Mas eles certamente foram felizes para sempre.

E eu aqui sendo egoísta, ocupando 4 IPs de uma vez só no meu único servidor. Na verdade, tô segurando esses 4 pra vender no Mercado Negro apartir de setembro de 2011.

Só sei que estranhava todas as vezes que vinha no painel e via algumas centenas de SPAMs pra moderar.

O interessante foi perceber que a comunidade brasileira de spammers em blogs tem se profissionalizado, andam comentando, em português, em vários posts, e caso o editor não perceba acaba aprovando o comentário e divulgando o link desses idiotas.

Olha um exemplo do site Mentalidade (sem link, óbvio, se quiser tem na imagem):

Então Barbie, Margart, Al, Silva, Shirley, Odilia e demais robôres: morram! ¬¬

Pois é, eu trabalho com um chato desses.

Tava ouvindo um pessoal conversar sobre pessoas de outros estados (aqui em SP) e como elas se adaptam, ou não. Como é a questão da educação, receptividade etc. Um disse que se der bom dia quando entrar no elevador os “nativos” vão achar estranho, do tipo “que que esse cara tá querendo pra chegar dando bom dia, meu?”

O chato disse:

- Em Curitiba é pior.

Ponto. Teve a manha de se meter, e não agregou nada.

Noutra ocasião fazia muito, mas muito, mas muito calor em São Paulo, tava infernal. O chato teve a manha de dizer:

- Em Foz (do Iguaçú) é pior. Lá é rodeado por morros, chove em todas as cidades vizinhas, menos lá, e blablabla… (sim, cansa mesmo)

Isso chega a ser motivo de zoação, quando faz muito calor aqui a gente “brinca” (com ironia, claro), que não chega nem perto do calor que faz em Foz. O chato ri.

Esse tipo de atitude é muito sacal. Uma coisa é agregar conteúdo ao assunto da vez, por mais irrelevante que o assunto seja, outra coisa é querer que todos admirem e se convençam que aqui está ótimo, é melhor do que lá, lá é foda – melhor ou pior…

Porra, aqui faz calor pra caralho sim. Tenha uma “pequena camada de tecido adiposo” (¬¬), ande alguns kilômetros pra ir e voltar do trabalho, e saia de roupa social no sol das 13h.

Porra, aqui – como em qualquer outro lugar – tem pessoas mal educadas sim. Não é virtude do lugar X ou Y ser pior não.

Isso enche… e eu então!?

Os conceitos abaixo são usados no controle de versão de códigos, e precisam ser conhecidos por todos os membros da sua equipe de desenvolvimento.

Trunk

A pasta trunk contém a cópia de produção. Ela tem as versões mais recentes dos programas considerados estáveis.

Branches

A pasta branches é aquela que contém alterações em funcionalidades existentes, como correções de bugs, implementação de módulos, inclusão de funcionalidades. Um branch sempre é criado a partir ou do trunk ou de uma tag e sempre ao final de um ciclo de desenvolvimento dará origem a uma tag.

Tags

Quando o desenvolvimento na versão do branch está considerado estável cria-se uma uma nova tag, formando assim um release. Dessa forma, uma tag é considerada uma versão que pode ser aplicada no ambiente de produção. Não há alteração em tags. Uma vez fechado o pacote do branch e enviado pra uma tag, qualquer novo desenvolvimento no branch resultará em uma outra tag.

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

Vá até o trecho da página onde tem Get a Product Key, escolha a versão apropriada e o idioma apropriado e clique em OK. Na próxima página, pode ser solicitado seu login e senha do Windows Live (se tiver conta no MSN, pode usar a mesma).

A cada reload é gerada uma chave para a versão que você escolheu. Esse procedimento é gratuito e você pode pegar quantos seriais quiser!!! Aproveite!