Se meu MacBook fizesse isto…
Monthly Archives: June 2009
A IBM está preparando uma série de 5 artigos detalhando o desenvolvimento de um serviço de compartilhamento de fotos utilizando a linguagem Perl. Nada de mais até aí, certo?
O interessante é que, primeiro, todo o código é disponibilizado para download e, segundo, o banco de dados está nas “nuvens”, mais precisamente, no serviço de armazenamento S3 (Amazon Simple Store Service), parte da Amazon Cloud.
Se você se interessa pelo funcionamento deste serviço de armazenamento da “nuvem” da Amazon, a série de artigos fornece material de excelente qualidade para que voce possa colocar as “mãos na massa”. Boa sorte!
Arnon Rotem-Gal-Oz é VP de pesquisa e desenvolvimento da XSights, uma empresa Israelense que desenvolve soluções móveis para disponibilizar conteúdo de mídia “tradicional” (jornal, catálogo, revistas…), em dispositivos móveis.
Ele também é autor do livro “SOA Patterns” e mantém um blog com informações sobre arquitetura de software, mobile computing, project management etc.
No preparou uma apresentação introdutória sobre REST (Representational State Transfer). É um .PPT com 31 slides no total que explica, de forma simples, o “estilo” de arquitetura de software, que é o REST, e qual sua relação com SOA.
A seguir um dos slides da apresentação:
Para quem se interessa pelo tráfego atual destes sites, segue gráfico com o resumo destes acessos elaborado pelo site Compete.com.
Alguns outros números sobre o Twitter no site da ComScore.com.
MoneyTree report é um estudo conduzido pela PricewaterhouseCoopers que monitora a atividade de Venture Capital nos EUA. A partir da base de dados da Thomson Reuters e do National Venture Capital Association.
Eles acompanham os investimentos que são realizados em 16 grandes grupos de industria:
- Biotecnologia, Produtos e Serviços ligados a atacadistas e importadores, Computadores e Periféricos,
- Produtos e Serviços de Consumo, Electrônicos/Instrumentação, Serviços Financeiros, Serviços de Saúde,
- Energia, Serviços de TI, Mídia e Diversão, Dispositivos e Equipamentos Médicos, Equipamentos de Rede,
- Distribuição/Varejo, Semicondutores, Software, Telecomunicações e Outros (empresas monitoradas e que não se encaixam na classificação acima).
O Relatório de Jan-Abr/2009 foi finalizado (PDF, 7 páginas) e mostra alguns dados interessantes:
1. Total Investido no Q12009 = USD 3 bilhões em 549 operações (queda de 47% em USD e 37 nas operações)
2. As empresas de Software tiveram o menor impacto de todos os segmentos analisados. Estas empresas receberam apenas USD 614 milhões (20,47% do total investido pelos Venture Capital Funds). Ainda assim, uma queda de 42% no total investido.
3. O relatório também monitora o valor investido por região dos EUA. Sem surpresa, o Silicon Valley ainda lidera o ranking, capturando 39% do total investido. Apenas a região de New York (NY Metro) , 3o. lugar, conseguiu atrair 11% do capital.
Nem os mais céticos do poder do Twitter terão argumentos contra este número: a Dell informa que conseguiu faturar US$ 3 milhões em 2008 através dos seus mais de 600,000 seguidores no Twitter.
Nestes dias de crise, nenhuma grande companhia pode se dar ao luxo de deixar de faturar US$ 3 milhões de uma forma tão simples como enviar micro-posts. A abordagem da Dell é enviar entre 6 e 10 pequenos textos no Twitter anunciando promoções, cupons de desconto etc. Algumas destas ofertas são divulgadas exclusivamente pelo Twitter (boa estratégia para atrair seguidores).
Até onde sei o próprio Twitter não tem participação alguma neste tipo de receita que as empresas gerar através de sua rede. Detalhes nesta reportagem da FastCompany.com.
Isto é uma boa receita para o próprio Twitter, que continua deficitário. Paradoxal não?
P.S.: atualizada às 20:58 do Domingo, 14/06, para correção do valor (grato Alexandre)
Professor Rajeev Motwani, 47, morreu hoje em sua casa, na cidade de Atherton, Califorina. Lecionava na Universidade de Stanford, no departamento de Ciências da Computação. Como vocês sabem, foi desta universidade que sairam os fundadores do Google, Sergey Brin e Larry Page.
Mr. Rajeev foi mentor de Sergey Brin. No seu blog pessoal, Brin comenta um pouco da importância que o professor Rajeev teve na sua vida, não apenas com as idéias e algoritmos que ajudaram na concepção do motor de buscas do Google, mas também como uma espécie de conselheiro pessoal e amigo.
A importância do professor Rajeev para o mundo da tecnologia pode ser resumida no texto final de Sergey, que reproduzo aqui: “…Today, whenever you use a piece of technology, there is a good chance a little bit of Rajeev Motwani is behind it.“
Depois da recente aquisição da Sun, Mr. Ellison (bem a seu jeito) já partiu para a ofensiva e fez o seu show na conferência JavaOne 2009.
O chefão da Oracle foi pessoalmente afirmar o compromisso da sua empresa na continuidade do Java e JavaFX (detalhes abaixo).
Jeremy Chone (SYS-Con.com) fez esta excelente cobertura, resumindo o compromentimento da Oracle com a plataforma criada pela SUN. Resumindo:
- JavaFX não é Java. Originalmente sabemos que JavaFX era para ser uma linguagem de script (como Groovy) mas, talvez por questões relacionadas a performance, virou uma linguagem compilada.
- Google Android não é um dispositivo baseado em Java. Uma observação importante. O Google Android é baseado em Linux. O SDK do Android “cross compila” o código Java para seu bytecode nativo. O desenvolvedor cria a aplicação em Java, mas a mesma não é executada em uma JVM no Android.
- Como ainda não temos uma JVM para o Android, e JavaFX precisa de uma JVM, como fazer para executar no sistema operacional do Google uma aplicação baseada nesta linguagem (JavaFX)? Discussão interessante, porém sem solução até o momento. Em tempo, no evento acima havia uma demo de uma app. JavaFX executando em uma Android… …tenhamos fé! Veja o vídeo abaixo!
- Por mais que não goste também, parece que o reinado de Java entre os dispositivos móveis já não é tão grande. Vamos lá: iPhone, o novo Palm Pre, Android etc. Segundo o autor do post original, tudo poderia mudar se Larry Ellison convencesse Steven Jobs a incluir Java nos seus iPhones. Convenhamos, seria perfeito… …sonhar não custa nada.
Eucalyptus - Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems – é uma infraestrutura open- source de software para implementação de “cloud computing” em clusters.
Eucalyptus é implementado com ferramentas disponíveis no sistema operacional Linux e tecnologia básica de Web-service. Tudo isto para simplificar a construção e manutenção da sua “nuvem”.
Tudo começou com um projeto da departamento de Ciência da Computação da Universidade da Califórina, Santa Bárbara. Deste projeto nasceu a start-up Eucalyptus System que se propõe a implementar a “nuvem” de forma comercial, em formato de professional services e suporte/manutenção.
NASA e uma das gigantes farmaceuticas, Eli Lilly, são alguns dos clientes da Eucalyptus System (vide este post com mais detalhes).
Uma das grandes vantagens do Eucalyptus (além do fato do mesmo ser open-source), é a compatibilidade com a API da Amazon Web Services. Isto na minha opinião é uma estratégia acertada da empresa, uma vez que não sabemos onde vai parar a discussão sobre um padrão para Cloud Computing.
Padrões são bons, só que infelizmente nem todos podem esperar pelo final desta discussão. Parece mesmo que este é o caso de quem chega primeiro dita o padrão. Neste ponto a Amazon está na frente.
Jurgen Appelo é o CIO de uma empresa da Holanda que já foi classificada como a #1 entre empresas que mais se destacaram em inovações tecnológicas. Ele mantém um blog onde escreve sobre tópicos relacionados desde conteúdo para a Internet até a metodologias e gerenciamento de projetos que utilizam metodologia ágeis.
Neste post, Appelo faz uma compilação bastante interessante de 10 princípios que devem guiar todo líder ou gerente de projeto que utiliza as práticas recomendas pelas metodologia ágeis. Discussões à parte sobre a eficácia destas metodologias, o ponto aqui é a discussão do tópico “Gerenciamento de Tempo”, uma das áreas de conhecimento do PMBoK, e um ativo altamente valioso nestes dias.
Vamos ao que interessa:
1. Use uma Definição de “Feito”
Eu poderia traduzir este princípio como “defina a tarefa como concluida se, de fato, ele estiver”. Se couber a palavras “mas” no final do seu discusso, esqueça, a atividade não foi feita, incluindo toda parte burocrática da atividade (apontamento de horas, levantamento de custos etc
Ele recomenda a leitura do artigo “The Definition od Done“. Neste texto o auto, de forma bem humorada, conta que seu pai era contador e tinha um grande aviso na parede da sala para os engenheiros desavisados. Neste aviso, havia um desenho de um papel higiênico e o texto acima: “The Job is not done until the paperwork is done”. Ou seja, na definição dele, o trabalho não estava finalizado se a papelada não foi preenchida. Perfeito.
2. Solicite Prazos bem Definidos e Exija o Cumprimento
Parece óbvio, mas não é: uma vez definido o prazo, não permita que estes se alterem.
Minha experiência pessoal inclui um tempo trabalhando em projetos de desenvolvimento no exterior, morando lá por algumas temporadas. Pelo menos nos EUA, nas empresas onde passei, isto é levado muito a sério. Você passou o prazo? Ok. Então você vai cumprir, “no matter what happens…“, é uma questão que remota a princípios culturais difícieis de explicar neste post, mas é assim que funciona.
Leitura recomendada: “Time Boxing is an Effective Getting Things Done Strategy”
3. Não Adicione “buffers” nas Tarefas
9 entre 10 líderes de equipe fazem isto (I Know!). É uma “praga” e, infelizmente, associa-se esta prática aos prazos de TI, que são sempre classificados como “não condizentes com a velocidade do negócio”. Quando o desenvolvedor ou o técnico passa a sua estimativa, ela(e) já informe com uma certa “margem de segurança”.
Isto nos leva ao “Paradoxo Tostines”. TI é culpada por errar estimativas, então aumentamos nossas estimativas para errar menos que, por sua vez, remete à questão de que TI demora muito para liberar as soluções… …percebeu?
(fonte: http://www.focusedperformance.com/articles/CCPM.htm)
Leitura recomendada: “Critical Chain Scheduling and Buffer Management…”
4. Não Tome as Decisões antes do prazo estabelecido
Em vista de toda discussão, parece paradoxal, mas tem uma razão. Se você tem um prazo até dia “D”, o autor sugere que você responda no dia “D”.
Qual o risco de responder antes? Mudanças de última hora podem ocorrer (e ocorrem!) e você terá que refazer o planejamento que já tinha feito. A não ser que a questão não deixe nenhuma margem para mudanças, aconteça o que acontecer, conte até 10 antes de responder imediatamente a questão. Isto pode trazer mais problemas que não compensa a sua intenção de “agilizar” o processo.
Leitura recomendada: “ ‘Real Options’ Underlie Agile Practice”
5. Reduza os Ciclos dos Processos
Quase um “mantra” das metodologias ágeis, nunca esqueça dos ganhos em reduzir os ciclos iterativos do processos.
Uma resposta rápida (feedback) vai retroalimentar mais cedo o processo e reduzir riscos.
Leitura recomendada: “Lean software development: Why reduce cycle-time?”
6. Limite a Quantidade de Tarefas que estão “in progress”
Quanto maior o número de tarefas em andamento, maior o risco de “escorregamento” destas atividades. Não existe um número mágico. Isto depende do porte do projeto, da experiência dos participantes e da equipe que gerencia o projeto, do ferramental disponível para acompanhamento do progresso das atividades etc.
Leitura recomendada: “Managing the Pipeline”
7. Mantenha a Disciplina
As regras de ouro aqui são: “resolver um problema tardiamente irá custar muito mais caro” e “começar certo, desde o início”.
Leitura recomendada: “The Power of Process” (recomendo!)
8. Limite o Intercâmbio de Tarefas
Sonho de 10 entre 10 gerentes de projeto, a mensagem aqui é evitar, a todo custo, tarefas intermediárias que farão uso “apenas por um dia, prometo….” dos recursos do projeto.
Leitura recomendada: “Human Tasks Switch Considered Hamful”
9. Atenção para as Horas-extras Frequentes
Na minha opinião, se isto é rotina no projeto, ou empresa, é um forte Indicativo de que algo está muito errado. Revisite as estimativas o tamanho da equipe, as fases do projeto, a experiêcia técnica dos recursos etc. Isto, quando comum, só gera desgate na equipe e perda de produtividade.
leitura recomendada: “The Case Against Overtime”
10. Separe Urgência de Importância
Atividade Urgentes e Atividades Importantes: escolha uma das duas. Realiza-las ao mesmo tempo é “embarcar em uma canoa furada”.
A prática diz que insistir em realiza-las ao mesmo tempo fará com que a tarefa Importante não será finalizada, gerado custos adicionais que poderião ter sido evitados.
Leitura recomendada: “A 10 Second Guide To Smoother Projects: Urgent vs. Important”
Boa sorte! Abraços,
Davi
