Faz tanto tempo que não coloco alguma coisa aqui que nem consigo mais enxergar um motivo para fazê-lo.

Mas agora que o período de semestral do servidor que eu paguei(uma pechincha) está vencendo, quem saiba eu use esse espaço para alguma coisa. Afinal como praticamente ninguém lerá o que eu escrevo, não vejo outro motivo a não ser a satisfação pessoal.

Meu querido amigo Igor Musardo me convenceu a participar do ETC Business aqui em Curitiba.
Esse encontro dos entusiastas do Twitter reuni pessoas com interesse de se comunicar, de falar sobre cultura, mercado de trabalho e como o Twitter pode ser uma ferramenta para as empresas. O evento é um bate-papo com várias pessoas que utilizam o Twitter como ferramenta de comunicação com os seus clientes.

Pesquisando por aí, eu descobri que existem pessoas que acreditam que o envio de e-mail vai reduzir drasticamente, principalmente porque isso já está acontecendo. Segundo a fonte citada, apenas 11% dos adolescentes enviam e-mails diariamente.

Esse desinteresse pelo uso de e-mails, se deve a facilidade, ao dinamismo e ao atrativo que outras ferramentas de comunicação são capazes, como o Twitter.

O Twitter é a media social na internet que está em completa acensão no Brasil, eu particularmente comecei a usá-la frequentemente ultimamente e gostei da experiência que tive.

Acredito que quem quer saber o que eu estou fazendo, planejando, ou pensando, basta me seguir no Twitter.

E se um dia eu tiver ativamente uma empresa, com certeza me relacionarei com os meus clientes através de uma ferramenta como Twitter.

Abraço.

Frio na barriga, foi isso que eu senti quando tomei a decisão de mudar de emprego. Quase quatro anos te ensinam a ser resistentes a esse tipo de mudança. É o famoso medo por medo. A não existia uma justificativa para o meu receio do novo, mas eu senti um frio de barriga exatamente igual quando eu descobri que mudaria de colégio na quinta série do ensino fundamental.

Estranho, um rapaz barbado como eu não deveria sentir esse tipo de coisa. Acredito que eu apenas senti o que meu ócio me ensinou durante anos. A falta da prática da tal atitude me mal acostumou.

Essa semana é a segunda no meu novo emprego e o que eu tenho a dizer é:

Por que não fiz isso antes? Por quê?

Ganhando um pouco mais, a 5 minutos de carro de casa, expectativas e esperanças renovadas, muita coisa a ser feita, muita gente confiando em mim, um ambiente muito bom e, principalmente, eu estou contente com o que eu fiz.

Abraço

Finalmente eu encontrei algo que se encaixa perfeitamente na minha experiência profissional, ano após ano escutando uma hipocrisia muito bem tramada e agora eu finalmente achei algo que retrata a realidade da vida de um desenvolvedor.

No blog gohorseprocess.wordpress.com eu consegui encontrar uma definição documentada de como eu trabalhei todos esses anos.

Simplesmente totalmente excelente.

Vejam alguns trechos da definição da eXtreme Go Horse Process:

1- Pensou, não é XGH.

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.

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.

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).

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).

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).

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.

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!

Quem um dia já programou em uma empresa com certeza está sentindo uma empatia forte.

Aquele abraço.

Magnetto é o nome de uma empresa do interior paulista que contratou o Igor Musardo para desenvolver um sistema de venda on-line de camisetas customizadas.

Para ajudá-lo, ele me chamou para desenvolver a parte da ferramenta gráfica de montagem/edição de camisetas.

Estou bem contente com o resultado desse freela e espero logo, logo, poder postar sobre a versão final da ferramenta.

Para acessá-lo, use esse link.

Abraços

Olha, minha cabeça quase explodiu. Ruby é uma linguagem de programação muito poderosa. Depois que eu vi o que é possível se fazer, eu realmente abri, e muito, a minha cabeça.

O que mais me chamou a atenção é a meta-programação, ou casa da mãe Joana, como assim eu a chamei.
Digo isso, e desse jeito, porque se pode tudo nessa linguagem. Você pode redefinir qualquer método de qualquer classe em tempo de execução, ou ainda, você pode definir qualquer tipo a qualquer momento.
Vamos para um exemplo. Iniciei o meu programa Ruby, no meio da execução eu posso criar a minha classe chamada MisterM, sim em tempo de execução. Depois eu posso instanciar um objeto dessa classe e criar novos método só para esse objeto, ou para todos os objetos do tipo MisterM.

Posso ainda definir um método, qualquer método, e redefini-lo quantas vezes eu desejar.  Como qualquer operador(+, -, *, /, etc) no Ruby é um método, eu posso sim redefinir até um operador. Não esquecendo que nesse universo tudo é objeto e tudo foi definido através de uma classe. Não existem tipos primitivos ou por valor.

Veja um exemplo.

Viu o que se é possível fazer? 1 + 1 = 0!!!! haha
Realmente Ruby dá muita liberdade para o programador.

Estou ansioso para o próximo sábado quando o professor explicar mais sobre Rails.

Abraço

Experiência é uma droga mesmo, às vezes fico divagando como era bom ser novo, não saber realmente como as coisas funcionam, não ter tomado a pílula vermelha e ter ânimo para fazer tudo independente da realidade enfrentada. Lembra daquele chavão: ignorância traz felicidade, ele é mais verdadeiro do que se imagina.

Sabe aquele prazer por um trabalho bem feito, a luta pela gratificação que deu certo. Fato que o projeto foi concluído esconde toda e qualquer dificuldade. Mas para que se importar com as dificuldades se o projeto foi entregue?

Uma analogia interessante é um atleta brasileiro quando ganha uma medalha num esporte de pouca expressão nacional. Poucas pessoas sabem o quanto ele teve lutar, a quantidade de dificuldades enfrentadas, a falta de patrocínio público e privado, o anonimato até chegar a medalha, etc. E quando ganhou a medalha, tudo continuou sendo esquecido para as pessoas de fora, afinal o próximo atleta que ganhar alguma coisa terá que enfrentar as mesmas coisas, e de novo, e de novo…

Somente quem já passou por isso sabe o quanto as coisas poderiam ser diferentes, quem já foi um programador cowboy e conseguiu deixar de ser um, sabe o quanto as coisas podem ser encaradas de uma forma diferente.

Em todas as empresas as quais eu já trabalhei eu tive que trabalhar no final de semana, em todas. Trabalhar de madruga, ou mais de 24 horas seguidas, é algo mais comum do que se imagina para cumprir os prazos. Chega ao ponto que quando um projeto está para “terminar” os gerentes dizem: “final de projeto é assim mesmo, temos que fazer horas extras”. Eu já escutei muitas vezes isso.

No próximo post eu falarei sobre a má cultura dos gerentes.

Abraços

Ela realmente aconteceu e a Unibrasil publicou uma nota falando do evento.

Gostaria de agradecer ao pessoal da Unibrasil pela oportunidade e a todos que assistiram a palestra.

Não foi exatamente como eu esperava, mas, de qualquer forma, foi uma experiência muito boa e espero poder repeti-la em breve.

Abraços

Como prometido, eu coloquei o projeto do FlyGuy no Google Code, para acessar use ESSE LINK.

Coincidentemente já existe um projeto chamado FlyGuy no Google Code, é um projeto “russo” que não tem nada dentro.

De qualquer forma, o código está todo lá!

Abraços

O título da palestra é: Desenvolvimento de Jogos em Flash/Flex de Forma Objetiva – O Caso Flyguy

Para quem me conhece essa história de FlyGuy existe faz anos, mas por que não utilizá-la para o seu verdadeiro fim? Passar conhecimento.

Apresentação pronta agora é só esperar!

E digo mais, essa palestrá será o startup deste blog.

Abraços