Diego Pacheco Tech blog

Writing software is fairly easy today.  There are Dynamic Languages, Frameworks, Libraries and lots of guides and styles about how to write good code that other humans will understand. Unfortunately, so few are captured about trade offs, this is specially hard since tech is constant change and evolution as requirements come and go is very hard to document this, so this kind of knowledge is hard to get it, specially because we are always building new things and at the scale we have different and bigger problems. The scale changes things, it creates new problems this requires a new way of thinking. There are matters like Anti-Fragility and Multi-Data center that are very hard to add it later, its way better get it from the get-go.  The hard part is that you don't know how much your business will grow and is hard for someone invest on rocket since tech before knowing where the business is going so in other words trade offs are really tough in this sense. Today it m...

 Everybody is looking for the cloud right now. Amazon Web Services(AWS) is leading and MS is getting aggressive with OSS and cloud, I think google was never competitive with cloud. The cloud market is ultra-hot . However there are lot of side effects on this let's say cloud rush. The basic one is the fact if you have a low skill operator or low skill architect this guys are dead. Because today is pretty ready to have solid and great architecture almost for free using amazon AWS. Off course there is a lock in effect on this. Amazon strategy already migrate monoliths to the cloud using lots of cloud services, dont get me wrong this services are great but you have a big infrastructure lock in with this. And depending how you do in out application you can have application lock in as well because amazon is amazon is not a RFC or a JSR spec.

Everybody is talking about DevOps now, which is good, but honestly DevOps is way bigger than what people are talking about. One of the CORE roots of devops is AUTOMATION of infrastructure - automate everything, that's true and that is so important, but that is not the only thing. DevOps is not a framework, is not a model, is not a process - DevOps are some experiences from folks around the globe who have had success in extending agile to new frontiers like operations - some people started a movement called Agile Operations which I think is great. DevOps is in some sense the evolution of the cultural change that agile and Lean promoted in development from the early 2000s. Now is the time to break more silos and continue to improve things. It's not easy, changing culture, but it is a necessary step for the evolution of software development.

Everything in life has good an bad things - there is no just win model - for sure there are things that are better than others but trade-offs will always exist. What's the greatest things around IT? There are several ones. The more I think I got into the *Framework Dilema* so what's the framework Dilema? It means as more as one constraint make it stronger it's also what make you weeak.  Let's say flexibility its a strong advantage it also be the source of the weakness - this is the duality I'm talking about.

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

Relembrando o post sobre o Banquinho . Que por sinal ainda acho que é uma visão a se ter sobre uma solução completa extremamente viável e simples. Hoje eu adicionaria outros pilares ao banquinho, seria como se fossem as cores secundarias, todas derivadas do bom e velho RGB , por isso não vou fazer mudança no banquinho. Mas vou falar de um pé sub-colateral, falando da rosa dos ventos agora.O ponto em comum entre ferramentas e processos, que estou chamado aqui de políticas. Acredito que esse seja o melhor nome, até por que esse termo é comum em gerência de configurações. Políticas? Hummmm.... Não. Não é esse tipo de política que você deve estar pensando. Falo de políticas de uso quanto a ferramentas, aqui ferramentas e processos se misturam, não falo apenas de workflow de trabalho, mas em formas de uso. Uso de Ferramentas Ferramentas servem diversos propósitos, os que considero mais importantes são: Diminuir o peso do processo Facilitar o trabalho das pessoas Automatizar tarefas repet...

Não sou adepto da política que trata o desenvolvedor como um desprovido de inteligência! Muitas vezes vejo que se criam arquiteturas e soluções para proteger os desenvolvedores dos frameworks ou sistemas. Isso é diferente de prover uma arquitetura adequada que diminui a complexidade do desenvolvimento, alguns chama isso de parede, outros chamas de uma grande desperdício de dinheiro. A Solução é evitar a arquitetura? No way! A arquitetura é sobre riscos e diminuir a complexidade do desenvolvimento. Isso significa que temos que pegar as maiores pedras no arquitetura, mas isso não elimina o trabalho do desenvolvedor. Tanto é que o arquiteto se envolve nos pontos mais importantes de Design e isso é diferente de se envolver em todos os pontos. Não se engane com os arquitetos de Frameworks! Já vi direto isso no mercado, muita gente acha que o arquiteto é o cara que mexe com frameworks. Acha que é o cara que decide se vai usar o JSF ou GWT, se vai usar Hibernate ou JPA. Arquitetura de softw...

Este não é um post sobre psicologia! Pode-se dizer que isso chega a ser um anti-pattern ou o mais puro desconhecimento de algo melhor. De qualquer forma já vi várias vezes no mercado frases do tipo: Os frameworks do mercado não nos atendem Os processos/metodologias do mercado não funcionam nesses contexto Esse tipo de arquitetura/metáfora não se aplica aqui Os usuários do meu sistema não pensam Os desenvolvedores são todos fracos Bom se você quiser podemos aumentar muito esta lista, com certeza você já deve ter ouvido algo assim em algum lugar ou pior em vários que nem eu :)! Um exemplo disso o Scott Ambler deu nesse post sobre adoção de agile . Não vou falar de agile ou criticar agile desta vez, mas só desta vez! Muitas vezes o ponto é a própria imaturidade da organização que ainda esta nas sombras da caverna ou simplesmente nem sonha o que são requisitos ! Esse tipo de egocentrismo é o legitimo tiro no pé! Por que a organização não dá espaço para que as coisas dos anos 60,70 e 80 e...

Ambiente sempre foi sinônimo de problemas! Mas não estou falando de aquecimento global. Pode parecer besteira mais um ambiente efetivo pode reduzir até 40% da complexidade de se desenvolver algo. Isso vem vem de técnicas de estimativas como o UCP . Não estou aqui para falar de UCP ou de estimativas no geral. Se você esperava encontrar um post sobre estimativas posso criançola-lo com esses outros posts anteriores sobre estimativas. Estimando com Scrum Estimativa não Exatimativa! Realizando estimativas de valor com Wideband Delphi Qual o assunto deste post então? Foco e Produtividade! Mas o que diabos o ambiente tem a ver com isso? Tudo. Quando estamos falando de TI podemos falar de 3 tipos de ambiente, vou classifica-los da seguinte forma: Ambiente de Desenvolvimento Ambiente Sociotécnico Ambiente físico Ambiente de Desenvolvimento Este é o ambiente do desenvolvedor aqui estão as ferramentas de apoio ao desenvolvimento como servidor de build continuo , maven , debuggers , profiles, ser...

Hoje(26/02/2009) saiu minha 2ª publicação OpenUP/Basic: Um framework Ágil e Unificado no UOL ( iMasters ) no canal de Gerência de Projetos . Esta publicação foi um post que fiz no meu blog em 21/06/2008.