Diego Pacheco Tech blog

Você não precisa ser agile, você pode fazer um projeto e ter sucesso sem usar agile. Mais softwares foram feitos sem agile ou qualquer metodologia, leia-se AD-HOC, do que com métodos agéis. Neste posto gostaria de esclarecer o diversos enganos que os ditos "agilistas" erram quando falamos de processos tradicionais e desenvolvimento de software. Em outro post depois falar dos pontos positivos, ou seja, do que é bom mesmo. Mas neste post vou focar neste equívocos que o pessoal comente ou omitem de propósito. Vou falar de algumas falácias também... Hoje em dia muitos colocam como os métodos ágeis sendo a única solução que funciona para o desenvolvimento de software, será que isso é verdade, será que não existem outras opções? Será que esta é a única solução e será que isso funciona sempre e não tem defeitos. Primeiro Passo: Escolhendo as palavras mágicas Palavras Mágicas Não posso negar o marketing dos caras é bom. Qual metodologia você gostaria de usar, para facilitar a sua esc...

No post anterior PaaS, Cloud Computing, Virtualização e o Futuro parte 1 comentei sobre algumas deficiências que existem hoje em dia no desenvolvimento de software. Dentre elas foquei nas dificuldades de criar um software que se escalável e no descolamento que existe do desenvolvimento para produção/operação. Na continuação do assunto, gostaria de salientar o obvio, ou seja, não existe bala de prata, PaaS, Cloud Computing e Virtualização não são soluções para todos os problemas e para todos os tipos de aplicações e cenários. Então vou começar falando um pouco mais do que se trata estas tecnologias, focando em conceito. Depois irei falar sobre o que anda acontecendo no mercado e o que pode vir a ser o futuro, acredito que muita inovação vai surgir nos próximos 2 anos e pode ser o novo paradigma de desenvolvimento de software. Virtualização Em poucas palavras estamos falando de abstração. Pode ser abstrair/deixar transparente o hardware, mas você tem acesso a este hardware mas como se ...

Nestes últimos anos a tecnologia evoluiu muito, principalmente pela necessidade cada vez maior de termos sistemas escaláveis e com um menor custo de operação. Quando estamos desenvolvendo software em média estamos falando só de 20% do tempo de vida da aplicação, ou seja, a maior fatia da aplicação ela vai estar em produção. Com a tecnologia atual ainda é muito forte a necessidade de se ter uma boa arquitetura e pensar muito em como desenvolver aplicações, isto envolve pessoas + ferramentas e Processo acredito que isso não vai mudar, mas podemos ter facilidades que hoje não se utilizadas ou não estão acessíveis a todos. Teoricamente plataformas como a da Sun(Java) e a da Microsoft(.net) já nos provem diversas facilidades as mesmas que não existiam quando se programava em C ou até mesmo Clipper. Ja foi um grande salto de paradigma da programação estruturada para a OO e para as plataformas de Java e .net porem ainda falta muito. Cada vez mais as aplicações ficam mais complexas, mais usuá...

É por mais incrível que pareça isto é muito comum no mercado. Mas não pense que falo só de Java, esta certo que 90% das empresas que trabalhei ate hoje, sendo de TI ou de negocio(não TI) tem frameworks feitos em casa. Neste post vou argumentar por que é uma péssima idéia fazer frameworks em casa e como isso pode ser muito ruim para sua empresa e para sua equipe, ou algo parecido com isso. Trabalhei com frameworks de VB 6.0, ASP 3.0, PHP, Java e até JS. Por incrível que pareça já vi louco fazer framework para JS em empresa de negócios(não TI). Um Framework? Vamos a algumas definições segundo o site thefreedictionary : 1 - Uma estrutura para suportar ou englobar algo principalmente um suporte em forma de esqueleto para alguma coisa a ser contruida. 2 - Uma plataforma de trabalho . 3 - Uma estrutura fundamental para trabalho. 4 - Um conjunto de suposições, conceitos, valores e práticas que constituem uma maneira de ver a realidade. Desculpem se a minha tradução não foi a ideal, mas acho q...

No post anterior , escrevi um pouco sobre BPM e bem como andam os padrões que seguem esse modelo, neste post pretendo falar sobre a ligação de BPEL com BPM. Vou citar outras referencias que confiram a minha visão de que BPM e BPEL talvez não seja o casamento perfeito. Quando falamos de BPMN, BPMS, simulação, estamos falando obrigatoriamente de BPM. Se falarmos de WS-BPEL, WebServices, WSDL podemos estar falando de SOA, mas nem sempre, usar WS-BPEL, WebServices, WSDL não significa ter SOA. Se você quiser saber mais sobre SOA pode ler esses posts: SOA: Cuidado com o Lock-In SOA sem BPMN e WebServices O papel do ESB em uma solução SOA SCA com Java Parte 1 SCA com Java Parte 2 A Diferença de EA e Arquitetura de Software Para maior entendimento desse post, recomendo muito a leitura do post anterior e esses outros posts que fiz sobre BPEL: Como vamos de BPEL Parte 1 Como vamos de BPEL Parte 2 - ODE Nos posts anterior sobre BPEL falei dos pontos positivos e neste post vou mostra...