Falta de cooperação entres departamentos e filiais
Você chega em um aeroporto e quer alugar um carro. Não fez reserva e não há mais carros disponíveis em uma das locadoras. Então você vai a outra.
Se a locadora pertencer a uma grande rede, ela poderia ver se há uma filial na cidade com um automóvel disponível, e sugerir a ida do futuro cliente até lá, ou mesmo pedirem para entregar o carro no aeroporto. Mas não foi o que aconteceu hoje com a Localiza quando cheguei ao aeroporto Santa Genoveva, em Goiânia. Quando vi que em duas locadoras não havia automóvel, sendo uma delas a Localiza, me dirigi a uma terceira, quando uma pessoa na fila me disse que havia outra Localiza na cidade. Peguei um folheto com o telefone no guichê da Localiza, pois a fila estava demorada, e vi o número lá.
Quase que eles perderam a locação. Quase fiquei sem carro. Nesse caso, a persistência do cliente em querer o carro e evitar uma nova fila de uma terceira locadora prevaleceram. Mas poderia ter sido melhor.
As coisas poderiam ser melhores nas grandes empresas se houvesse um entendimento melhor da estratégia, de como fidelizar clientes e o que está a disposição para parcerias e sinergias. Funcionários deveriam ser recompensados por isso. Não faz sentido em ser grande, se você não é forte. Os grandes que não são fortes só são mais lentos.
Ainda sobre o QCon, faltou mencionar a apresentação do Facebook.
Eles usam PHP, MySQL, Memcache.
Têm 50 bilhões de page views e 120 milhões de usuários ativos.
Não recomendam armazenamento de dados em um ponto centralizado, e sim pensar no sistema com repositórios de dados em tuplas com particionamento. Principalmente se forem informações que exigem frescor, como por exemplo, número de pessoas em uma sala de bate-papo, participando de um fórum, ouvindo uma música, placar de enquetes, etc. Informações que só agregam se forem do último momento não precisam estar em um banco de dados relacional.
Recomendam usar serviços ou memcache para queries globais, como, por exemplo, quais os grupos mais populares na minha rede?
Eles têm 25TB em memória de memcache.
Eles usam o memcache através de UDP, pois gera menos overhead para manter conexões e menos uso de memória de TCP para os buffers. Parece fazer todo sentido para redes locais.
Pegue a ferramenta certa para o trabalho certo: eles usam C++ ou Java em forma de servicos, ao invés de PHP, em alguns casos. Para isso, eles usam thrift (http://incubator.apache.org/thrift/) . Vou investigar mais, antes de postar sobre isso.
Strategic Design Palestra ministrada por Eric Evans - autor do livro - Domain Driven Design
Ele já começou questionando o que se considera um sistema bem desenhado. O que motiva as pessoas a fazerem refactoring? Logo na seqüência ele já enunciou que nem todo sistema grande será bem desenhado. Um sistema grande que é importante, é também vivo e tem mudanças a todo tempo. A arquitetura sempre precisa de refactorings. Porém, de nada adianta colocar isso para o patrocinador do projeto ou unidade de negócio sem atrelar a um valor agregado compreensível. Esse ponto de vista é diferente daquele de refactoring em times ágeis, onde não necessariamente há inclusão de nova funcionalidade. Acho que é mais uma questão de postura de negociação do que o conteúdo do refactoring em si. Você tem de procurar vender a idéia de refactoring pensando em redução de custo, ou para facilitar as manutenções, ou mesmo aumentar a capacidade do sistema. Sem dogmas técnicos para o cliente ou product owner. O importante é ele ver algum valor no negócio. E nem sempre ele vai concordar. Isso me fez lembrar um caso. Tenho um amigo que já me contou uma situação em que um departamento de TI de um banco grande no Brasil decidiu comprar uma máquina bem mais poderosa em termos de processamento, ao invés de fazer uma mudança banal no sistema como, por exemplo, trocar o uso intenso de banco de dados por cache. Não é o negócio do banco ter o melhor sistema e talvez nem faça sentido a economia versus alocação de pessoas, desenvolvimento, testes e gestão de risco e impactos em mexer em sistemas.
Voltando à palestra, Eric citou um caso que ele vivenciou: - um sistema antigo de 10 ou 12 anos de idade - cliente infeliz
Como ele estruturou o refactoring do sistema: - generic subdomains - genéricos no ambiente de trabalho - supporting subdomains - tem haver com o domínio, mas não é a essência - core domain - pequena parte que representa o que as pessoas procuram para gostar do produto
Do que eu entendi da classificação acima seria, para um sistema de blog, por exemplo:
- generic subdomain: sistema de e-mail para envia mensagens de anúncio da página ou post do blog. Uma estrutura genérica de servidores de e-mail;
- supporting subdomains - o sistema gerenciador de arquivos e quotas do conteúdo do internauta para armazenar blogs, fotos, vídeos, áudios, etc.
- core domain - subsistema de edição de posts e exibição da página.
É claro que esse tipo de classificação é contextual. Quero dizer, para o dono do produto blog, o core domain é certamente o que está citado acima, pois é onde o produto dele vai atrair ou não usuários. Porém, se você estiver com uma demanda de aumento de capacidade de armazenamento de contéudo do internauta, mantendo custo médio menor, o seu cliente ou definidor de requisitos deverá ser uma pessoa com perfil mais de operações e técnico. Por isso, nesse caso, o core domain passará a ser outro. Novamente, pensar sem travar em dogmas e contextualizar para tomar a melhor decisão é importante.
Os melhores programadores tendem a procurar os subdominios genéricos. Tem problemas mais interessantes. Isso se parece bastante com o que estou acostumado ver também. Os domínio mais genéricos tem relação com infra e o desafio técnico é maior.
Lembrando do papel do arquiteto no refactoring, Eric disse que às vezes é difícil conduzir isso com alguns programadores. Depois de alguns ajustes que são colocados, alguns programadores não tão experientes tendem a fazer ajustes fora do combinado no core domain. Como é no core domain que está a essência do valor para o negócio, isso, muitas vezes, leva a uma meritocracia injusta, onde uma pessoa não tão qualificada tecnicamente gera uma percepção de eficiência, e desorganiza a arquitetura do sistema. Por isso, ele aconselha a colocar as pessoas mais experientes no core domain também.
Embora as pessoas tendam vigiar o pior programador do time, o que causa mais danos é o segundo pior, pois ele está fora do alcance e não está em evidência.
Em resumo: coloque as pessoas melhores no core domain. http://domaindrivendesign.org/
Qcon 2008: Apresentação adicional sobre o Google App Engine
Atualmente o uso de Google App Engine é gratuito, mas eles estão pensando em cobrar. O que eles garantem que será sempre grátis é: - 500MB storage - 2GB banda /mês - em torno de 5 milhões de page views/mês
Quando for cobrado, o preço pode ser: - CPU - 10-12cents/h - GB storage - 15-18cents/h - banda saída - 11-13 cents GB - banda entrada - 9-11 cents GB
Funcionalidades presentes hoje: - memcache - ambiente de execução Python - uso de persistência (Big Table) - poder fazer http requests - manipulação de imagens (tenho de olhar mais) - https
Mais sobre essa apresentação, você pode encontrar no link abaixo. A senha é qcon .
Participei de um tutorial de 4 horas sobre o google app engine (http://code.google.com/appengine/) ministrado pelo Mano Marks. Esse é um serviço em que você pode escrever o seu código Python, e colocá-lo para rodar como se fosse um CGI na infra-estrutura de data center do Google, tendo uma plataforma para persistência (Big Table). Você coloca a aplicação para funcionar e não tem de se preocupar com a quantidade de servidores onde ela será executada.
Set up do google app: Muito fácil em Mac. Não sei se é assim no Windows
3) comece a usar o GoogleAppEngineLauncher e leia um projeto já existente. Os botões dele vão te fazer navegar, pois a usabilidade do launcher é muito boa.
Tudo pode ser escrito em Python, por enquanto. Promete evoluir para outras linguagens, mas não garante COBOL. @:-)). Novidades serão anunciadas para o primeiro trimestre do ano que vem.
Por que Python? C++, Java e Python são as linguagens de programação no Google. Eles começaram a usar o Python. Um amigo (Gleicon) me disse que talvez eles tenha escolhido Python para poderem filtrar mais facilmente o que o desenvolvedor pode fazer. Por exemplo, o Python que é executado no Google App Engine não permite escrita em file system. A persistência só pode ser feita em Big Table.
BigTable é diferente de bd relacional. O relacionamento entre entidades se dá entre objetos e não entre classes. Logo há uma maior dependência da aplicação para manter a base de dados consistente e íntegra. Para acessar a base de dados, você deve usar GQL (google query language), que parece com o SQL, mas só tem select.
Cada aplicação tem um arquivo app.yaml para definir a aplicação. Lá diz onde qua o arquivo .py vai iniciar a aplicação.
Segundo o instrutor, a motivação do Google é: - melhorar a web - eventualmente será cobrado - quanto mais aplicações, mais publicidade e pessoas navegando
Os domínios podem appspot.com ou próprios
Eles também usam memcache api. Com vídeos educacionais, eles ensinam como os desenvolvedores a construírem aplicações mais escaláveis. Para isso, ele recomendda ver o vídeo building scalable web applications with google app engine com Brett Slatkin. O vídeo está abaixo.
Apresentação muito boa de David Hussman pensando já além de como os agilistas normalmente encaram as discussões de processo. Na realidade o que ele disse no início e depois reforçou no final é que é preciso mover o pensamento do como seguir o processo para o porquê seguir o processo. Essa é a maneira sustentável de fazer as pessoas encararem as responsabilidades delas no desenvolvimento, e terem autonomia. Na realidade acho que a visão do porquê ao invés de só o como, deveria servir para todos os processos e boas práticas. Realmente há coisas que são passadas em treinamentos e conferências, e até mesmo praticadas dentro da empresa que não tem razão de ser, ou já tiveram razão de ser algum dia, mas como alguma outra evolui, o procedimento sendo executado se tornou obsoleto. Indo mais além, tudo na vida que é hábito deveria ser entendido o motivo e não só a realização. Tenho impressão que é essa a linha que as escolas construtivistas seguem.
Em seguida, ele disse para primeiro praticar os métodos ágeis e depois deixá-las em improvisação. A minha visão disso é que cada cultura e contexto tem seu modo de encaixar e premiar as pessoas. Pode ser ruim improvisar inicialmente em um projeto que custe 1 milhão de reias e que esteja sendo esperado para ganhar 4 milhões por ano. Dificilmente uma consultoria terá como bancar isso perante a direção da empresa. Não é só uma questão de ser conservador ou não, é que infelizmente os métodos ágeis não tem como mostrar antecipadamente o resultado de ganho de eficiência na entrega. Todo mundo que participa de desenvolvimento, sabe que não há tubo de ensaio para isso. O que se vê é que as pessoas entregam mais próximas da data combinada um código melhor testado, mas para isso acontecer, os ciclos de entrega têm de ser pequenos, seguindo plan-do-check-act.
Desenvolvedores, negócio e testes devem trabalhar juntos. Sim, isso é muito importante. Mas acho que ele poderia ter detalhado melhor o que é trabalhar juntos aqui. Embora eu desconfie de como e porquê isso deve acontecer, muitas vezes converso que ainda não praticaram processos ágeis e elas confundem de como os intergrantes do time, área de negócios e testadores têm de trabalhar a favor do desenvolvimento de software.
Segue o site da empresa em que David Hussman trabalha: www.devjam.com .
Recomendações de contratação de gestores de projetos e scrum masters
O fórum sobre pmi e scrum que participei no Scrum Gathering 2008 me fez pensar sobre o que deve ser valorizado em um gestor de projetos e como isso se reflete no uso de processos orientados a forte planejamento (quase sempre nomeados waterfall) ou aos processos ágeis. Durante entrevistas ou mesmo discussão de problemas em processos ou projetos, procuro ver quando o gestor do projeto tem noção de impactos em custos e prazos e quanto ele está protegendo para que o escopo do projeto seja cumprido. Eu faço isso, porque acredito que custo, prazo e escopo é o básico em termos de gestão para que um projeto tenha chance de ser concluído, mesmo que não respeitando as três restrições. O gestor que atenta para esses parâmetros de gestão tende a ser mais proativo, e deixar os stakeholders comunicados de maneira objetiva sobre mudanças e impactos em planejamento. É muito ruim para a organização, quando você se depara com uma situação que está fora do planejado há algum tempo e que terá impactos significantes em marketing, vendas, qualidade de serviço, etc. Os clientes do projeto, alta gestão e até mesmo os product owners tendem a ver os membros do projeto com desconfiança, pois acham que os problemas estão sendo omitidos. Além de custo, tempo e escopo, acho muito importante o scrum master ou gestor de projeto, no caso do UOL, ter background técnico em computação. Sendo ou não scrum, no UOL, requisitos de escalabilidade, baixo custo médio de transação ou requisição são fundamentais. Não, o scrum master e nem o gerente de projetos sozinhos vão garantir isso, mas eles podem ser críticos e fazer as perguntas corretas a cada decisão tomada. Uma abordagem que eu gosto de fazer com times e até mesmo com scrum master e gerente de projetos é elaborar cenários de melhor e pior caso para o sistema, produto ou negócio para decisões de arquitetura. Desenhando e conversando com as pessoas, elas vêem para onde irá o que eles decidiram no médio prazo, e por si mesmo refazem ou elaboram melhor o que propuseram. Mas não dá para fazer isso sem conhecimento e experiência prévia no assunto. Tendo as características acima, o profissional tende a ir bem com scrum ou processos waterfall. No caso da pessoa ser muito experiente em gestão de projeto e não conhecer scrum, o principal cuidado a ser tomado é se ela sabe que o scrum tem de ter times que se organizam sozinhos. No caso é importante até perguntar se isso seria um incômodo para ela durante o trabalho, podendo até ser considerado um impeditivo para a contratação. Acho que os times e líderes dos times têm de ser estruturados de maneira que se evite o microgerenciamento. No médio prazo ele cria dependências desnecessárias, gargalos de produtividade e pior, não faz com que as pessoas evoluam rapidamente.
Estudando o livro do Kerzner oitava edição para a prova do PMI achei a expressão "Act of God". Assustado, pensando que o PMI também fosse uma casa fundamentalista do pessoal do Bush, resolvi verificar no http://www.dictionary.com se isso era um expressão. Ufa! É uma expressão antiga para identificar desastres da natureza.
Eu ainda acredito no PMI.
act of God
An unforeseen and uncontrollable natural event, such as a hurricane, fire, or flood. For example, The publisher shall publish the work within twelve months except in case of delay caused by acts of God such as fires or floods or other circumstances beyond its control. It most often appears in legal contracts, where it is used to indemnify one party against a disaster that prevents it from carrying out the contract's terms. [Mid-1800s]
O Tablet PC que uso não veio com suporte a WPA. O site da Toshiba traz nenhuma informação sobre wpa e windows xp para o modelo Portege 3500. Olhando o nome do fabricante, fiz uma pesquisa que deu uma noção de como está isso para diversos fabricantes.
Após o uso de f12 aparece uma tela com ícones sem texto e com pouca usabilidade. É normal o Toshiba não travou. Escolha a melhor maneira fazer o boot com as setas.
Escrito por Alexandre às 22h05
Leia este blog no seu celular