William Shatner and Kaley Cuoco Strike a Pose
segunda-feira, 25 de março de 2013
Código - Merge ou sobreposição? Depende...
Vamos entender isso direito.
Algumas perguntas simples para iniciar. A aplicação na qual você trabalha é um software de prateleira? Você está desenvolvendo código específico para um cliente específico? O código no qual sua empresa está trabalhando é alterado por outras empresas? Você trabalha em uma aplicação cuja propriedade é da softwarehouse, e que está em vários clientes, mas um determinado cliente está sempre pedindo customizações?
A aplicação na qual você trabalha é um software de prateleira?
Olha só, se sua aplicação é de prateleira, e há poucos desenvolvedores, esse é o cenário ideal. Nessa situação não há customização. Exemplo, um aplicativo simples para IPhone; um website em que você é o proprietário e o próprio desenvolvedor.
Nesse caso o percentual de merges pode chegar a zero.
Mas e no caso de eu estar em 2013 e estiver preparando a versão de 2014?
Será feito um merge para o lançamento, depois vão existir dois produtos. 2013 e 2014. A versão 2013 sofrerá correções mas não influirá na versão 2014, e eventualmente essa versão será descontinuada (claro isso é um cenário idealizado, não precisa ficar nervoso. É apenas para fins didáticos)
Você está desenvolvendo código específico para um cliente específico?
Até o final do desenvolvimento não há necessidade de merge pois o produto não foi implantado no cliente. Ou "seje" o produto não existe! Então para que ficar fazendo merge em uma coisa que não existe? Como um produto novo, que ainda não foi implantado pode ter mais de uma versão, sem ter nem ao menos a versão alfa? Minha sugestão, faça sobreposição.
E depois que for lançada a versão alfa? Bem aí, aparecerá a versão beta. Mas antes de colocar a versão beta no ar, não vejo necessidade de ter a versão beta1, beta2, beta3, beta4, beta5 e etc... Que tal lançar a versão e depois criar outra e assim por diante. Ao invés de criar uma miríade de versões?
E depois que a aplicação foi implantada no cliente? Daí a coisa muda de figura, pois, dependendo do tamanho da aplicação, o cliente poderá pedir customizações que tem pouca relação umas com as outras. Nesse caso, aparecem várias versões e o merge é inevitável. OU você se planeja, negocia com o cliente e entrega tudo de uma vez. Isso evitár trabalhos de merge que são caros apesar de invisíveis.
O código no qual sua empresa está trabalhando é alterado por outras empresas?
Esse cenário é um potencial causador de cefaleia. Nesse caso todo cuidado é pouco. Mas veja bem. Uma outra empresa, tem uma versão do código que você está alterando, e em algum momento fará o merge com a versão que está em produção. Você também tem uma versão do código que será adicionada ao código principal. Só aí já temos três versões. A sua, a da outra empresa, e a principal. Agora imagine se você tivesse vários baselines deste código? O que você acha que acontece com o risco de algo dar errado na hora do merge.
Neste cenário o merge é inevitável, mas de novo, planeje-se, negocie e entregue todas as suas alterações em uma versão só (claro isso é um cenário idealizado, não precisa ficar nervoso. É apenas para fins didáticos).
Você trabalha em uma aplicação cuja propriedade é da softwarehouse, e que está em vários clientes, mas um determinado cliente está sempre pedindo customizações?
Não quero me torna repetitivo, mas é o seguinte. Agrupe o máximo de requisições possíveis em uma versão e só então faça sua entrega. Fazer uma branch para cada requisição do cliente é a receita para falência (agora pode ficar nervoso, o que eu falei aqui não é para fins didáticos. I mean it!). Nesse caso o merge será provavemente inevitável.
MERGE***
PRÓS**
Possibilidade de desenvolvimento em paralelo de demandas com fraco relacionamento. A não ser que você tenha uma grande equipe de teste que teste vários desenvolvimentos em paralelo na mesma aplicação. Se só existe uma pessoa que homologa, para que fazer desenvolvimento paralelo? Há nexo?
POSSÍVEL CONTRA**
Proliferação infinita de branches.
SOBREPOSIÇÃO DE CÓDIGO***
PRÓS**
Menos código para ser gerenciado. Fluxo de deploy simplificado.
POSSÍVEL CONTRA**
Maior dificuldade de paralelizar desenvolvimento (mas não é impossível).
CONSIDERAÇÕES FINAIS
Há outros prós e contras que não foram mencionados, mas achei esses os principais.
Tenho experiência tanto em empresa que trabalhava com 0% de merge, e com empresa que trabalhava com 0% de sobreposição. Nenhuma das duas coisas é saudável. A sobreposição de código é um mundo ideal com poucos conflitos, não há muito o que dizer à respeito.
Da questão do merge, entretanto, há muito o que se debater. Há por exemplo um mito, estranhíssimo, que parece espalhado pelas TI's do Brasil, de que um merge bem feito implica em um código correto. Qual é a lógica disso? Não, merge por si só não corrige erros de requisito mal feito, ou de codificação displicente. Se você era um desses que achava que o merge tinha o poder que corrigir um requisito mal feito, MYTH BUSTED!
CONCLUSÃO
De tudo que escrevi acima, o que acho mais importante é:
"Planeje-se, negocie e entregue todas as suas alterações em uma versão só!"
Ou seja, mais do que uma questão técnica, esta é uma questão de GERÊNCIA. Mas é claro que um ALM bem implementado também é de suma importância.
PS: Este assunto é muito chato, eu sei. Por conta disso, escolhi esse video para você assistir se refazer dessa chatice toda:
sábado, 23 de março de 2013
Leonard Nimoy tem twitter!!!! Aaaaaaaaaaaaaaahhh!!!!
Verdadeiros nerds sabem que é Leonard Nimoy. Se esse nome não lhe diz nada, você provavelmente não é um nerd.
https://twitter.com/TheRealNimoy
sexta-feira, 15 de março de 2013
Migração de Sybase para MSSQL Server (Cutting through the bull****)
Antes de mais nada, vamos estabelecer algumas premissas. Premissa no. 1 - Estamos falando de um lugar em que a tecnologia Microsoft é a predominante. Premissa no. 2 - Existe na empresa um desejo generalizado de realizar a migração dos bancos de dados para MSSQL Server. Dito isto, podemos continuar.
Ao longo dos meus mais de dez anos de carreira de tempos em tempos sou questionado sobre a migração do banco Sybase para MSSQL Server. "É seguro?", "Quais são os riscos?", "Isso irá afetar a paz mundial?", "Causará mutação em fetos humanos?". Até que me provem o contrário, a migração não afetará a paz mundial (não diretamente), e definitivamente não causará mutação em fetos humanos. Então, quais são os reais problemas?
Primeiro aspecto a ser observado
Factibilidade da migração - Para quem trabalha com qualidade de desenvolvimento de software, sabe que padrão é uma coisa difícil de estabelecer e manter nas organizações brasileiras. Assim, a incidência de código não padronizado, ou seja, ANSI SQL, é quase sempre muito alta, quando começamos a analisar as procedures, triggers e views (os três objetos que repreentam o principal problema na migração).
Mas então se os objetos que mencionamos acima não estiverem escritos em imaculado ANSI SQL devemos abortar o projeto de migração? Nada disso. O SQL produzido no Sybase, mesmo não sendo ANSI SQL, não é algo completamente alienígena para o MSSQL Server. Isso porque, acho que todo mundo sabe disso, este último, teve o seu core originário do Sybase.
Se ainda está em dúvida, leia este paper
Segundo aspecto a ser observado
Estratégia - E quanto a estratégia de migração? São necessários cientistas da NASA para fazer a migração? Não, não são necessários cientistas da NASA. Isso porque este tipo de migração é uma técnica de domínio conhecido há pelo menos cinco anos.
Antigamente era necessário ler um paper , um pouco chato eu admito, de algumas centenas de páginas. Esse paper da microsoft era um manual com um passo-a-passo de todo o processo de migração.
Mas desde o ano passado o caminho foi encurtado devido ao aparecimento do SSMA, SQL Server Migration Assistant.
Para detalhes desse migrador, acesse:
Para baixar, acesse:
O SSMA resolverá pelo menos 80% do problema. Mas e depois?
Terceiro aspectoa ser observado.
Risco - "Ai mas como eu garanto que o código migrado para MSSQL Server não tem nenhum erro?!!!!!! Aaaahhhhh!!!!!" , você provavelmente ouvirá isso do seu gerente, superintendente ou diretor. Não se intimide. Responda, com muita calma e serenidade, o óbvio. Testando! Ou, responda de uma forma mais elaborada, PDCA, Plan, Do, Check, Act.
"Mas e quanto ao risco de dar errado?". OK, vamos lá. Existem duas formas de responder essa pergunta. A primeira é a ironia, "Se você não quer correr riscos seja dono de uma funerária. O risco é próximo do zero. É um setor que nunca está em crise". Vamos agora a forma mais polida, eu diria.
Escolha o processo mais crítico relacinado a sua migração. Faça um snapshot do seu banco (uma foto) antes de executar esse processo. Execute o tal processo. Faça outro snpashot. Guarde os dois.
Depois que fizer a migração das procedures, views e triggers. Migre os dados do primeiro snapshot(Sybase) para o banco já migrado(SQLServer). Execute o processo mais crítico. Compare os resultados do SQLServer com o segundo snapshot(Sybase).
O que eu descrevi acima foi apenas uma sugestão. Mas certamente o DBA da sua empresa terá uma ideia melhor.
Conclusão.
A verdadeira questão não é, "SE é possível migrar", e sim, "QUANDO migrar". Hoje em dia, a migração do Sybase para SQLServer é muito mais um desafio de planejamento do que um desafio tecnológico propriamente dito.
PS: HÁ!
segunda-feira, 4 de março de 2013
Pois é, a tal da governança SOA
Sabe qual é a diferença entre vender areia no deserto e vender um projeto de governança SOA para um empresa? Vender areia no deserto é mais fácil.
Já tentou explicar o retorno que uma governança SOA traz para o representante de uma organizção? "Vou organizar os seus serviços", você diz.
O outro responde, "a é? e o que eu ganho com isso?".
"Meu caro, você ganhará a reusabilidade", diz você com ar de superioridade.
"A é? Em quanto tempo esse projeto se paga?"
"Hummmm de um a dois anos"
"É mesmo? Mas até lá o que eu ganhei?"
"Veja bem, você evitará duplicação de serviços"
"É mesmo? Hummmm, dois anos? Hummmmm, mas qual o produto final disso?"
"A reusabilidade"
"Sei, sei"
"Mas isso não é um produto tangível"
"Bem, tangível, tangível não é, mas, a economia é grande"
"Ou seja, eu não vou ganhar nada com isso"
"Bem, você deixa de perder, que é uma forma de ganho"
"Mas..., isso não gera lucro"
"Diretamente, não"
"Hummmm..."
Essa é uma conversa fictícia, mas que poderia continuar até o final dos tempos. E antes de achar que todo mundo é obrigado a entender que a Governança SOA é um benefício óbvio para qualquer empresa, pense que estamos falando de algo que não é trivial de entender. As pessoas tem todo o direito de ficarem receosas em investir em algo que é por definição abstrato.
Para resolver esse dilema comecei a estudar um OpenSource chamad WSO2 | Governance Registry.
E depois de dois meses de estudo e testes, cheguei a conclusão que a ferramenta atende o cenário no qual estou inserido na empresa onde trabalho.
Depois que se entende o objetivo pensado pelos desenvolvedores do WSO2 | Governance Registry, tudo fica infinitamente mais simples.
No meu caso estou utilizando como insumo básico os endereços do tipo wsdl. A partir deles gero toda a base que preciso para realizar a governança.
Depois de feito o upload das definições você terá os xsd gerados pelo wsdl, e uma definição da classe que gerou wsdl. Não é a coisa mais fácil do mundo de entender, mas com um pouco de esforço você chega lá. Como pesistência estou utilizando um SQLServer (é mais prático).
Encurtando a história, caso a governança SOA na sua empresa não esteja no topo da lista nas prioridades, essa ferramenta pode te ajudar a iniciar o processo da governança com quase nenhum custo pois é um opensource.
Prós: é um opensource e em tese não terá a licença para pagar.
Contra: É um opensource escrito em Java e não tem instalador.
Já tentou explicar o retorno que uma governança SOA traz para o representante de uma organizção? "Vou organizar os seus serviços", você diz.
O outro responde, "a é? e o que eu ganho com isso?".
"Meu caro, você ganhará a reusabilidade", diz você com ar de superioridade.
"A é? Em quanto tempo esse projeto se paga?"
"Hummmm de um a dois anos"
"É mesmo? Mas até lá o que eu ganhei?"
"Veja bem, você evitará duplicação de serviços"
"É mesmo? Hummmm, dois anos? Hummmmm, mas qual o produto final disso?"
"A reusabilidade"
"Sei, sei"
"Mas isso não é um produto tangível"
"Bem, tangível, tangível não é, mas, a economia é grande"
"Ou seja, eu não vou ganhar nada com isso"
"Bem, você deixa de perder, que é uma forma de ganho"
"Mas..., isso não gera lucro"
"Diretamente, não"
"Hummmm..."
Essa é uma conversa fictícia, mas que poderia continuar até o final dos tempos. E antes de achar que todo mundo é obrigado a entender que a Governança SOA é um benefício óbvio para qualquer empresa, pense que estamos falando de algo que não é trivial de entender. As pessoas tem todo o direito de ficarem receosas em investir em algo que é por definição abstrato.
Para resolver esse dilema comecei a estudar um OpenSource chamad WSO2 | Governance Registry.
E depois de dois meses de estudo e testes, cheguei a conclusão que a ferramenta atende o cenário no qual estou inserido na empresa onde trabalho.
Depois que se entende o objetivo pensado pelos desenvolvedores do WSO2 | Governance Registry, tudo fica infinitamente mais simples.
No meu caso estou utilizando como insumo básico os endereços do tipo wsdl. A partir deles gero toda a base que preciso para realizar a governança.
Depois de feito o upload das definições você terá os xsd gerados pelo wsdl, e uma definição da classe que gerou wsdl. Não é a coisa mais fácil do mundo de entender, mas com um pouco de esforço você chega lá. Como pesistência estou utilizando um SQLServer (é mais prático).
Encurtando a história, caso a governança SOA na sua empresa não esteja no topo da lista nas prioridades, essa ferramenta pode te ajudar a iniciar o processo da governança com quase nenhum custo pois é um opensource.
Prós: é um opensource e em tese não terá a licença para pagar.
Contra: É um opensource escrito em Java e não tem instalador.
Considerações finais
Se você trabalhar com a suite toda. Ou seja, se você estiver usando o ESB e o aplication server da WSO2, seu aproveitamento será ainda maior. No meu caso, os webservices criados onde trabalho são gerados a partir de tecnologia WCF/.NET; tecnologia que não é supertada pelo aplication server da WSO2.
Mas mesmo utilizando apenas uma parte da solução total da WSO2, o custo benefício é muio grande.
Se você trabalhar com a suite toda. Ou seja, se você estiver usando o ESB e o aplication server da WSO2, seu aproveitamento será ainda maior. No meu caso, os webservices criados onde trabalho são gerados a partir de tecnologia WCF/.NET; tecnologia que não é supertada pelo aplication server da WSO2.
Mas mesmo utilizando apenas uma parte da solução total da WSO2, o custo benefício é muio grande.
Conclusão
Se o seu mundo é Microsoft, ainda assim, considere utilizar o WSO2 | Governance Regisgtry.
Se o seu mundo é Microsoft, ainda assim, considere utilizar o WSO2 | Governance Regisgtry.
Há!
Assinar:
Postagens (Atom)