Alteração do Blog

Pessoal,

Esse blog mudou para http://blog.rodrigoallemand.com.br/

Atualizem!

Mudanças… Novamente!

Não cheguei a comentar aqui, mas (rs) troquei de empresa novamente… em menos de 2 meses…

Não, não foi por causa do Struts 1!
Não, não foi por causa do EJB 1!
Não, não foi por causa da falta de interesse dos gerentes!
Não, não foi por causa da completa falta de entendimento do projeto, mesmo falando de cliente!
Não, não foi nada disso!

Quando eu entrei na antiga empresa, o pessoal já estava avisado que eu estava participando de um outro processo seletivo que tinha prioridade.

Pois bem. Este processo acabou e o resultado foi que agora eu sou um dos lideres/arquitetos do INCa.

Meu desafio agora é dar suporte a uma equipe de 9 pessoas (só de desenvolvedores, inicialmente) em 5 projetos diferentes.

Os maiores pontos de escolha para este novo desafio foram:

- A causa é nobre, já que é pra ajudar no estudo do Câncer
- A equipe é nova (juniores de alto nivel), sem vícios e prontos para cair dentro de código.
- A metodologia é “faz o que vc achar melhor”, conforme dito pelo Diretor
- O clientes são participativos
- Os prazos são acordados em iterações
- O conjunto de frameworks é novo, podemos usar o que acharmos de melhor para a equipe, com exceção do uso de ApplicationServer free…
- Há muito problema nos sistemas antigos, mas isso não será visto agora (oportunidade)
- O nivel dos sistemas antigos e das pessoas que os montaram parece ser… hum…. er… baixo!
- É CLT. E é bem mais do que as ditas “grandes” pagam…

Bem. É isso!
Pretendo voltar a escrever com frequência.

Até!

Mac + Linux?!

Conforme dito neste artigo do pessoal Applemaníaco Appleníaco (Obrigado, Guilherme!), o pessoal da Ubuntu quer colocar o Linux pra rodar sobre a plataforma Mac (Intel, claro!). WTF!?!?

Só tenho uma coisa a dizer: é bem mais barato você comprar qualquer laptop que seja e colocar o seu Linux preferido. Afinal, foi pra isso que o Linux foi feito! Pra você não ter que pagar por softwares proprietários para ter um simples “PC”, desde a época que M$ e a IBM tinham um acordo onde pra vc ter um PC, teria que comprar um Windows! Mac não é um simples PC!

Normalmente, as pessoas que poderiam fazer isso são:

- aquelas que não conhecem nada de Mac e querem um iBook porque acham ele mais bonito que aquele Toshiba grande, pesado e preto!

- ou são aqueles usuários maníacos por linux, especialmente pelo Uuntu, e que mesmo tendo um Mac, poderiam pensar em colocar um linux só pra ter o mau gosto de usar linux! (rs! Sei que vc não vai tentar isso…)

Mac é para um pequeno publico, que quer um sistema operacional e uma plataforma boa para trabalho… Mac não é pra ver os “miguxos na net e no MSN”…

A ideia desse post era alertar vários amigos sobre isso…. Mac é pra Mac OX… Mac com Linux seria um Subaru com motor de AP de Gol…. Existe, mas ninguem fala bem desse cara!

Problemas a vista

Como o MeioBit já escreveu, a portabilidade de números entre as operadoras de telefonia celular vai finalmente sair do papel! Se bem que isso já se falava desde a época de Telefonica aqui no Rio, onde eu trabalhei por 7 anos. Mas agora eu acho que vai mesmo!

…
O trabalho de implantar a portabilidade numérica no país, a partir de 1o de setembro deste ano
…
Serão beneficiados os assinantes dos códigos DDD 14 e 17 (São Paulo), 27 (Espírito Santo), 37 (Minas Gerais), 43 (Paraná), 62 (Goiás), 67 (Mato Grosso do Sul) e 86 (Piauí) neste primeiro momento.

Entre a primeira e a segunda etapa de implantação, há um prazo de 60 dias, já que a nova fase começa em 3 de novembro.
…
Também por decisão das operadoras, as duas últimas cidades em que a portabilidade vai chegar são, justamente, as mais populosas, Rio de Janeiro e São Paulo, nas duas últimas fases do projeto.
…

O texto acima foi retirado daqui!

O serviço estará disponível para números fixos e celulares a R$ 10,00 por troca (//TODO: Verificar este preço), sem limite de nada. Alguns idiotas já me perguntaram se é possivel mudar um número fixo para um celular ou vice-versa. Vc tb tem essa duvida?! Espero que náo…rs

A ideia é criar uma abertura no mercado, aumentar a concorrência e, por consequência, aumentar a qualidade do serviço, já que antigamente o maior problema era vc ter toda a sua rede de amigos conhecendo o seu número e depois ter que alertar a todos sobre a mudança! Sem contar todo aquele trabalho de copiar telefone de chip pra chip (mas isso eu ainda acho que vai ser necessário)… isso era uma Barreira…

Mas tudo tem dois lados. Já fiquei sabendo, que a interconexão no momento da ligação (aquele tempo que se perde do momento que o Usuário Chamador aperta o SEND até começar a tocar no Usuário Chamado) será “um pouco maior do que o normal”. Um pouco mairo quanto?! Seria isso um boicote?

E o tal do bônus – aqueles créditos que “intra-operadora”  é mais barato ou grátis? Como ficarão? Existirão, aqui no Rio por exemplo, os 99**-*** da Claro, da Vivo, da TIM, da Oi e da Nextel?! E falando em Nextel, como ficará a ligação grátis de 78 pra 78?! rs

Bem, que o negócio vai complicar, ah, isso vai! Vamos esperar!

P.S.: O inicio da portabilidade será no mesmo período de liberação do iPhone 3G… tsc, tsc, tsc… quem for vender iPhone vai receber um montão de números das outras operadoras…

Rapidinha: Novos e Velhos Desafios

Imagine que vc é chamado para trabalhar em uma grande multinacional de desenvolvimento de produtos, para fazer uma grande alteração em um produto para uma grande telecom. Imagine, agora, que tudo isso será feito usando Struts 1.0 e EJB 1. Imaginou? Eu já imaginei…Eu só não consegui acreditar ainda…

Criando lideranças

Este tópico não é exclusivo para o pessoal de IT. Ele pode facilmente ser extendido a todos que estão em algum tipo de organograma, seja na parte mais alta até a parte mais baixa.

Exercer um cargo de liderança é algo que deve ser bem balanceado. Vc precisa ser ao mesmo tempo ‘técnico’ e ‘pessoal’. Vc precisa ser técnico para poder guiar os subordinados e pessoal, para criar um bom relacionamento na equipe. Se vc é muito técnico e pouco pessoal, as pessoas podem te ver como um ditador, onde tudo o que fala é certo, por mais que vc esteja certo. Se vc é muito pessoal e pouco técnico, as pessoas podem te encarar como um lider sem respeito, que não entende do que está liderando ou coisas do tipo.

Recentemente passei por uma situação dessas. Deu-se a criação de um cargo de liderança técnica sobre todas as equipes. Com isso, a estrutura de empresa ficaria assim:

• Gestor geral (1 pessoa)
• Staff na gestão (1 pessoa)
• Lider técnico (1 pessoa)
• Lider do projeto (1 pessoa por produto)
• Time de projeto (diversas pessoas por produto)

Com isso teriamos um ponto para os problemas ‘administrativo’ e outro para os problemas ‘técnicos’. Muito bom para o pessoal de ‘cima’ e sem muita mudança para o pessoal de ‘baixo’. Com essa mudança, o Staff na Gestão ficaria mais livre pra fazer a gestão de todos os projetos/produtos, deixando para o lider técnico somente os ‘bits’.

A escolha dessa pessoa não surpreendeu a ninguem. Todos sabiam que ele tinha completa competência para o cargo, porem, o lado pessoal dele não era balanceado com o lado técnico. Por várias vezes eu – e todos os outros – o vi chamar a atenção de alguem em tons acima do normal, fazer criticas destrutivas sem fundamento, achar que o que ele faz está correto e todos estão errado. Mas se vc for um pouco mais frio pra analisar, as coisas não tomaram tanta proporção quanto pereciam. O que amplificou isso tudo foi a falta do lado pessoal equalizado. Isso causa um clima ruim na empresa. Muitos já pensam “Não sei se vou aguentar esse cara” e já ficam na retranca, dificultando ainda mais o terreno do novo lider.

Portanto, se vc quer chegar a algum nivel de liderança e ser reconhecido e aceito como lider, equalize os seus lados pessoal e técnico. E acredite, uma pessoa que tenha um lado pessoal bem formado e que consiga trazer a equipe pra perto, é sempre bem visto, por pior que seja o seu lado técnico.

10 coisas para afundar um projeto

setSarcasticModeOn();

1. Pegue um projeto com um cliente que não sabe o que quer e feche um prazo de entrega, até mesmo se vc não tiver noção do tamanho do buraco. Se conseguir um projeto complicado é melhor. Se conseguir um projeto complicado e que não seja a atividade fim da empresa, melhor ainda!

2. Monte uma arquitetura ‘perigosa’ – onde requisitos não funcionais vitais, como segurança, por exemplo, devem ser aplicados pelos desenvolvedores, e não pela arquitetura – e que dificulte ao máximo o desenvolvimento. Quanto mais enrolado, melhor.

3. Monte uma equipe, desfaça a equipe, monte outra, treine, desfaça novamente, realoque pessoas, transfira recursos para outro projeto, mesmo que o projeto já tenha começado ou melhor, faça isso no fim do projeto.

4. Na semana da entrega, arrume alguma coisa que impossibilite a equipe de trabalhar… uma boa idéia é a mudança de site da empresa! Não esqueça de proibir os desenvolvedores que levem códigos para as residências e não – em hipótese alguma – disponibilize a estrutura de versionamento para acessos remotos.

5. Fique longe do conhecedor do negocio – vulgo cliente, se possível em estados diferentes. Mas o principal: não tenha contato algum com o cliente. Faça uma barreira entre o time de desenvolvimento e os reais donos do negócio. Por exemplo, quando um desenvolvedor te pergunta “Como é essa regra aqui mesmo?”, responda, “Calma que eu vou mandar um email para o ‘cara’ e daqui a dois dias eu te respondo”.

6. Mude o banco de dados, no dia da entrega, se possível! Acrescente tabelas, campos. Altere relacionamentos.

7. Não faça testes! Nem documentação, javadocs ou coisas do tipo! Isso é coisa para fracos!

8. Tenha os requisitos na mente, e não em papel. User stories é história pra boi dormir. E se possivel, passe essa funcionalidade para uma pessoa que não conhece nada do negócio. Mas não esqueça: conhecimento é como senha: pessoal e intransferível.

9. Como o cliente não está por perto, vá falando para o desenvolvedor as particularidades da funcionalidade sobre demanda. Siga, sempre que possível, o script abaixo:
Desenvolvedor: “Acabei a funcionalidade X”
‘Líder’: “Beleza! Mas vc fez a funcionalidade XPTO?”
Desenvolvedor: “O quê?!? (com cara de WTF?!)”
Líder: “É, existe a regra XPTO que faz isso, isso e isso”
Desenvolvedor: “Mas isso estava descrito aonde?”
Líder: “Lugar nenhum… vc não me perguntou tambem, né!”
Desenvolvedor: “Mas eu terei que mudar muita coisa agora. Vou começar logo com isso então.”

10. Massa de dados é uma coisa que não deve existir. Faça alterações no banco para que cara registro precise ser deletado. Divida o projeto em pacotes/componentes seguindo a metodologia ‘non-sense’. Faça com que qualquer alteração necessite de um build completo, restart do servidor, redeploy e coisas mais que dificultem ainda mais o trabalho de construção.

setSarcasticModeOff();

Atente para 10 coisas que podem levar o seu projeto ao sucesso sem muito esforço.

1. Iterações e prazos reais, tanto para equipe quanto para o cliente
2. Arquitetura é para facilitar, e não para atrapalhar. Tambem não gere código. Diminua a quantidade de código. Menos código, menos falhas.
3. Time antes de tudo! Ela não precisa ser o que o mercado te dá de melhor, mas precisa ser um grupo que passe confiança, internamente e para as outras partes de um projeto. Muitos falam em familia, como a Familia Scolari, a familia Bernardinho. Seleção nada mais é que o melhor elenco disponivel, seja em tempo, dinheiro, geografia, etc.
4. Ambiente de trabalho… preciso dizer mais alguma coisa (caso sim, leia o link)?!
5. O levantamento só precisa ser total ao fim do projeto.
6. Modelagem de banco de dados é uma arte. Modelagem de sistemas (UML, basicamente) tambem é uma arte. Deixemos os artistas trabalharem em conjunto para uma obra final melhor! Porem gênios normalmente brigam entre-si. É nessa hora que vc entra, para fazer a flexibilidade entre os dois mundos.
7. Faça testes, codifique, documente. Faça testes, codifique, documente. Repitam comigo!
8. User Stories são levantadas pelo desenvolvedor com o especialista do negócio. Não crie barreiras nessa comunicação.
9. Documente as peculiaridades. Muitas coisas podem fazer sentido em tempo de desenvolvimento. Talvez, no momento de manutenção, o mesmo código possa não ser tão claro.
10. Monte uma estrutura de projeto. Estrutura mesmo. Build, massa de dados, componentização, facilidade de build, HotDeploy, Mocks, e coisas que vc só deve ter em tempo de desenvolvimento.

Hello world!

Resolvi não mudar o título do Post não… Até porque, como tudo hoje em dia, o que é um inicio (no sentido de aprendizado, primeira vista) é um Hello World!

Eu sempre lí bastante; livros, blogs, foruns, revistas, artigos, etc. Mas nunca me bateu uma vontade de escrever algo. Ultimamente vejo muita gente escrevendo, algumas coisas extremamente úteis; outras, noticias de um cotidiano mais do que cotidiano; e outras poucas (mas existente) coisas totalmente inúteis.

Porem, em uma entrevista, me perguntaram se eu mantinha algum blog (?!?). Encarei a pergunta como uma simples duvida, e que o contratante queria apenas mais uma entrada no seu Feeder… Mesmo assim, respondi que não era responsavel por nenhum blog mas que pensaria na ideia. Pensei e ele está aí!

A ideia aqui é debater sobre as tecnologias e as metodologias que cercam esse nosso mundo de desenvolvimento num plano mais informal, tentando criar uma linha de raciocínio que nos leve ao melhor de cada coisa.

Bem, inicialmente é isso! Pretendo (do verbo “se o tempo deixar”) escrever bastante aqui! Aguardem!