Category Archives: old_tellesfera

Camera de Vídeo 360

Camera 360º Ultimamente está saindo nos blogs uma câmera de vídeo de 360º. No meu mestrado eu fiz exatamente uma câmera desta. Olha o protótipo aí do lado. Ela se conecta ao computador via uma conexão firewire e o computador realiza a fusão das 5 imagens que são capturadas individualmente pela câmera.

A aplicação original que eu pensava para esta câmera era captura de reuniões (estilo RingCam da Microsoft). Interessante que o pessoal da empresa que o vídeo foi divulgado está filmando festas.

Para quem for realmente curioso, você pode baixar a dissertação aqui (pdf 900k).

10 Perguntas para um Hacker – O Macintosh Brasileiro

outro relembrar é viver.

Em outra coluna apresentei Andrew “Bunnie” Huang , um hacker de mão cheia que faz as coisas acontecerem. Ao final daquela coluna perguntei quais eram as histórias brasileiras semelhantes que mereciam ser compartilhadas.

Eu fiquei esperando e continuo esperando contribuições naquele sentido. Temos que mostrar as coisas boas que acontecem aqui, as histórias de engenheiros e técnicos que produzem ou produziram coisas no nosso Brasil. Aproveitando o mote resolvi relembrar uma história pouco conhecida da computação nacional. O Macintosh brasileiro. E resolvi fazer isso entrevistando o Rainer Brockerhoff, hacker de mão cheia que conhece as minúcias do Macintosh como, eu acredito, nenhum outro brasileiro conhece e que participou do desenvolvimento do Macintosh brasileiro. Fiz isso no modelo de 10 perguntas:

1) Qual é a sua história e como você entrou no projeto do Macintosh brasileiro?

Comecei a trabalhar como programador em 1969, na época praticamente só havia computadores em bancos e universidades. Em 1977 comprei um Apple II para uso doméstico e alguns anos depois, quando começaram a surgir os primeiros microcomputadores nacionais, comecei a trabalhar num dos fabricantes, a Quartzil. Lá fui responsável pelo sistema operacional e aprendi projetar hardware também. Quando o Macintosh foi lançado em 1984 me interessei e trouxe um dos primeiros ao Brasil; trouxe também ferramentas de desenvolvimento e comecei a fazer pequenos programas para uso próprio.
Eu já conhecia o pessoal da Unitron dos tempos de Apple II. Quando o hardware do Mac Unitron já estava praticamente pronto, me convidaram a ajudar com o software, e claro que me interessei.

2) Como era composta a equipe e qual era a sua função na equipe?

Creio que eram umas 10 pessoas. Eu era consultor externo, como não moro em São Paulo, e ia para lá uma vez por semana. Fiz boa parte da “Toolbox” – a parte da ROM responsável pela interação com aplicativos e com o usuário. Outras pessoas fizeram os drivers de dispositivos e as rotinas gráficas. Devo ter feito talvez 30% da ROM, é difícil avaliar hoje.
Mais no final também fui responsável pela ROM de inicialização – o equivalente, na época, ao firmware – e também fui convidado pela SEI (Secretaria Especial de Informática) a preparar um parecer técnico detalhando como havia sido feita a engenharia do software Mac Unitron.

3) Como foi realizado o processo da engenharia reversa do software?

Um programador da Califórnia, Steve Jasik , havia desenvolvido um produto chamado MacNosy (“narigudo”) para decodificar a ROM do Mac. Usamos isso bastante, mas também havia outras ferramentas, cujo nome exato não me lembro mais.

4) Como era o processo de desenvolvimento? Quais eram as ferramentas disponíveis? Vocês desenvolviam em qual plataforma?

Era um processo de fazer chamada por chamada do sistema. Para cada uma, eu pegava aquela parte da saída do MacNosy, que era em linguagem Assembler não muito simplificada, e fazia anotações ou alterações para fazer a lógica mais inteligível. Incluia nessa listagem “patches” (alterações) introduzidas pelo disquete de sistema para consertar bugs ou expandir as funções, e comparava isso com a descrição daquela chamada na documentação da Apple. Então eu recodificava aquela função em linguagem C, tínhamos um compilador chamado Aztec C que era bem razoável. Depois, conferia se o código objeto gerado realmente executava as funções desejadas. Tudo isso rodava no meu Mac 512K. A partir de certo ponto tínhamos uma ROM que já podia ser testada.
Isto era possível, também, porque o Mac Unitron tinha o dobro do espaço disponível de ROM do Mac da Apple. Os programadores da Apple tiveram que usar de muitos truques para fazer o software caber, enquanto que tínhamos espaço para absorver as ineficiências do C e ainda consertar vários bugs direto na ROM.

5) Você viveu o período da reserva de mercado, na tua opinião quais foram os prós e contras daquele período?

Acho que foi uma reserva equivocada e inadequada, que não atingiu seus objetivos; especialmente porque pouca gente, na época, entendia os aspectos técnicos ou previa o progresso da globalização. Todos se basearam em indústrias que levaram décadas para se estabelecer e não previram a aceleração da tecnologia digital. Não era viável fabricar chips no Brasil, mas não se podia importar – isso retardou por mais uma década a implantação de carros com motores injetados, por exemplo.
Na empresa onde eu trabalhava, ostensivamente “protegida” pela reserva, precisávamos de um analisador lógico para desenvolver o sistema. O analisador continha um microprocessador, portanto não podia ser importado sem um processo de isenção que levou quase 3 anos! Como toda a indústria estava nessa situação, a reserva foi um grande fomento ao contrabando.

6) O projeto do Macintosh nunca saiu por interferência governamental. Você pode contar um pouco desta história?

Como eu disse, fiz um parecer técnico detalhando que o projeto era legal dentro dos conceitos, da época, de engenharia reversa. Acompanhei o restante só através de informações de terceiros, mas o que me disseram foi que a SEI fez dois laudos técnicos favoráveis – examinando hardware e software separadamente. Durante o processo de aprovação, sob pressão americana, o congresso aprovou a lei 7646 (Lei do Software), que retardou ainda mais as coisas, e o projeto teve que ser refeito e reapresentado. Em 1998 o CONIN rejeitou o projeto. O CONIN era composto de 8 representantes da sociedade civil e 8 ministros do governo. 7 representantes independentes estavam presentes e votaram a favor do projeto. 7 ministros votaram contra e um se absteve. Diante do empate, valeu o voto contrário do ministro da ciência e tecnologia, presidente da comissão.

7) Qual é a tua opinião sobre os limites legais da engenharia reversa?

Não sou advogado, então isso é apenas uma opinião. No caso Unitron, o mercado brasileiro era fechado à Apple, e ela não tinha registrado patentes aqui. E obviamente a Unitron não conseguiria vender no mercado americano; então era uma disputa mais em cima de conceitos de propriedade intelectual. A engenharia reversa foi feito com total acesso ao original, coisa que hoje em dia não seria aceita; mas dentro do conceito de reserva da época era válido.

8 ) E depois do projeto do Macintosh? O que você fez?

Por vários anos, fui diretor técnico de uma empresa que fabricava monitores médicos digitais, que foi até um exemplo de como se poderia desenvolver tecnologia aqui sem copiar ninguém, e concorrer com aparelhos importados. Em paralelo montei um dos primeiros provedores comerciais de Internet no Brasil. E claro, sempre dei consultoria e desenvolvi software para Macintosh. Hoje me considero semi-aposentado mas continuo fazendo shareware para Mac.

9) Você é um dos raros desenvolvedores brasileiros para Macintosh. Como é desenvolver para esta plataforma e como você consegue colocar os teus produtos no mercado?

Acho que o mais importante é visar o mercado global, trabalhar somente pela Internet e ficar em contato com a comunidade de desenvolvedores. É necessário dominar o inglês muito bem, claro. Escolhi um nicho de mercado que facilita isso – shareware para usuários de melhor nível técnico, e para os colegas desenvolvedores. Vou frequentemente a congressos no exterior e publico vários softwares grátis e/ou “open source”. Tudo isso gera publicidade e reconhecimento pela comunidade.
Nada disso adianta se os produtos não forem bem acabados e funcionais. O mercado Mac é muito exigente nesse sentido. A minha tradição familiar é da marcenaria artesanal, meu pai por exemplo era especializado em produzir modelos de madeira para fundição que tinham que ser extremamente precisos. Sou o primeiro não-marceneiro da família, mas herdei a obsessão de polir e aperfeiçoar ao máximo os meus produtos. Se precisasse do shareware para sobreviver, e dedicasse tempo integral a isso, certamente seria possível – especialmente agora, com o mercado da Apple explodindo em várias direções.

10) Você estava no WWDC que a Apple lançou o Intel Inside. Qual foi a tua opinião na época e como você encara hoje? O que você espera da Apple do ponto de vista de software nos próximos anos.

Fiquei surpreso mas, depois de saber detalhes, otimista. Eu sempre disse que não seria possível fazer um bom emulador de PowerPC em Intel, mas uma vez que conseguiram (através do “Rosetta”), foi melhor. A Apple estava muito dependente da Motorola e da IBM que tinham outras idéias sobre a plataforma. Não acho o x86 ideal como arquitetura, mas é que temos hoje em dia. E a história mostra que a conversão foi bem-sucedida, e em menos tempo que anunciado.
O que vimos do Leopard e do iPhone me deixou muito animado quanto ao futuro do software, especialmente do OS X. Ainda não temos dados precisos, porque ambos só vão sair por volta de junho.

Links:

Para saber mais do Macintosh Brasileiro vejam os links abaixo. É interessante que até o nome de Sarney é envolvido na história. Se tiverem mais curiosidade procurem por “Macintosh + Unitron” no Google, vem bastante coisa:

http://inventabrasilnet.t5.com.br/mac512.htm
http://chester.blog.br/mac512.html
http://sts.imv.au.dk/arbejdspapirer/WP1_web.pdf (Referência ao Sarney)

O Steve Jasik também tem uma história interessante relativo a um ícone “Stolen From Apple” que é relatado no site sobre a história do Macintosh Folklore.

Google: além da pesquisa, o que temos?

Relembrar é viver, escrevi isso em 2006.

Duas semanas atrás eu me deparei com este site: DabbleDB. É um serviço de banco de dados da Web 2.0. Permite montar tabelas, importar dados, criar relacionamentos, gerar relatórios, exportar para vários formatos, inclusive RSS, e deixar o banco de dados público em uma URL para colaboração. Depois de ver o vídeo do produto e o achar excelente, indiquei-o para um amigo. Momentos depois recebi a resposta:

- Vou esperar a versão do Google.

Imediatamente fiquei com esta pulga atrás da orelha. Sempre os produtos oriundos do Google são melhores? Com certeza alguns dos produtos são fantásticos e eu os uso diariamente. Posso mencionar o mecanismo de busca, o serviço de email e o Google Desktop. Mas, além disso, quais são os grandes sucessos do Google? E que fazem sentido econômico?

Não podemos nos esquecer que o Google é uma máquina de fazer dinheiro com um único produto. Anúncios vendidos com base em palavras chaves. 99% do faturamento deles vêm desta linha de receita. Esta é a força da Google e a sua fraqueza. Todos os outros concorrentes estão atrás desta receita e o Google está procurando intensamente ampliar o seu portfólio de produtos. Mas qual é o sucesso desta empreitada?

Esta semana a Bussiness Week trouxe uma matéria interessante sobre este assunto. Nesta matéria vemos os seguintes dados:

  • Google Talk: tem hoje 2% do Mercado de instant-messaging
  • Google Finance: está em quadragéssimo lugar entre os sites financeiros.
  • Gmail: tem um quarto de usuários do MSN e Yahoo.
  • Orkut: somente faz sucesso no Brasil. Nos EUA ele tem 1% do mercado com o MySpace liderando inquestionavelmente.

Sobre o Google Maps, a própria Google fica preocupada. Veja este vídeo do Seth Godin em uma palestra na sede da Google. Um dos funcionários pergunta ao Seth qual foi o erro deles no Google Maps. O Google Maps foi lançado, todo mundo achou fantástico, mas não pegou. A pergunta e a resposta estão no momento 43 minutos e 13 segundos do vídeo.

A filosofia de utilizar 20% do tempo dos funcionários para projetos pessoais e que podem retornar para a empresa é interessante quando se tem um caixa enorme para gastar, mas, em tempos mais difíceis, este processo de desenvolvimento dos produtos se sustenta? A própria Google, hoje, duvida e estão revendo o seu processo de desenvolvimento de produtos, como fica claro nesta matéria. ([CEO] Eric [Schmidt] and [co-founder] Larry [Page] acknowledged that we really do need to apply a little bit more organization to some of what’s happening here at Google).

O que o Google faz é novo? Na minha opinião não é. O processo de lançar produtos e criar um hype em torno deles não é novidade no nosso mercado, de uma forma um pouco diferente e com um nome um pouco esquecido. Vaporware. A empresa que mais utilizou esta tática com sucesso foi a Microsoft. Criava uma série de produtos e anunciava previamente as suas funcionalidades e tendências. O mercado como um todo esperava a posição que da Microsoft antes de dar o próximo passo.

E como era o financiamento desta estratégia? Inicialmente com o dinheiro do Windows. Depois, sucessivamente, foram montados os negócios do Office e de servidores. Veja este pequeno extrato abaixo, relativo ao ano fiscal que acabou em 30 de Junho de 2005:

  • Windows desktop: $12.2B
  • MS Office: $11.0B
  • Windows Server, SQL Server, .Net development tools: $9.9B
  • xBox: $3.3B
  • MSN sites, Search: $2.3B
  • Great Plains, SMB business: $0.8B
  • Windows Mobile: $0.3B

As duas primeiras linhas de negócios têm uma margem em torno de 70%, a terceira linha, em torno de 33%. São linhas de negócios estáveis com um crescimento lento. Com o recurso delas, financiam-se as outras linhas de negócios que ainda necessitam de investimento, mas que têm um potencial muito maior de crescimento. Se fôssemos analisar estes mesmos números há alguns anos atrás, veríamos que a grande vaca leiteira era o Windows e que, naquela época, financiava o negócio Office. Posteriormente, a receita das duas linhas de negócio ajudou a financiar a linha de servidores.

Em resumo: As duas empresas têm muitas semelhanças nas suas estratégias. Existe uma diferença de abordagem: o Google mais caótico numa tentativa de não sucumbir ao dilema do inovador (Innovators Dillema) e a Microsoft mais pragmática tentando atacar o próximo grande mercado, sem atirar de forma tão aleatória quanto o Google.

E qual é o grande problema? O fator de lock-in do Google é baixo. Caso a MSFT consiga igualar a qualidade da pesquisa dela no MSN Search, a migração dos usuários é muito mais simples que no caso de um sistema operacional para o outro, com todo o legado de software existente. Não se esqueçam, o maior ativo da Microsoft é a sua API (Win 32) e a quantidade de software escrito para ela.

E, finalmente, o pessoal já começa a fazer piada do processo inovador do Google, mas não vamos esquecer a história. Da mesma forma que a Microsoft usou a pilha de dinheiro que tinha em mãos para financiar e ajustar uma série de negócios que hoje são rentáveis, o Google tem caixa suficiente para fazer o mesmo. É não deixar outros chegarem na sua principal vaquinha leiteira, enquanto ampliam o portfólio. E eles estão de olho nisso, vejam o último relatório (arquivo PDF 500k) para investidores. A partir da página 39 até a 54 estão os riscos do negócio.

Eu odeio plano de negócios (business plan)!

Eu odeio plano de negócios, acho que temos um fetiche em relação aos planos de negócios. Acho também que o ensino de empreendedorismo no Brasil privilegia extremamente o plano de negócios que deveria ser uma mera ferramenta, um instrumento para levantar a discussão dos itens essenciais de uma empresa. O que acontece é que se fica tão embevecido com o instrumento – plano de negócios – que se esquece do essencial: produto e mercado.

Deixa eu relatar uma história que ilustra o meu pensamento, estava visitando uma incubadora e me apresentaram uma empresa como extremamente promissora. Eu me sento para conversar com o pessoal, o papo foi mais ou menos assim: (vou manter as características da empresa em segredo, sem constrangimentos)

  • Camilo: Oi! Tudo bem? Eu soube que vocês estão desenvolvendo um sistema para X. Excelente. Posso ver o seu plano?
  • Empreendedor: Ah! Sim, nós temos 3 planos de negócios! (ops! 3???)
  • Camilo: Não! Eu estava falando do plano do produto. Algum tipo de especificação, cronograma. Quando vocês pensam lançar a primeira versão minimamente funcional?
  • Empreendedor: Entendi. Estamos esperando lançar algo em 6 meses.
  • Camilo: Que bom. Como vocês estão resolvendo a questão do problema Y (tecnologia essencial para o projeto deles)
  • Empreendedor: Problema Y? Não pensamos nele ainda.
  • Camilo: Uma pergunta. Vocês dizem que vão lançar algo em 6 meses e não sabem ainda como abordar o problema Y? O que vocês vão lançar em 6 meses?
  • Empreendedor: Estamos discutindo o que vamos lançar em 6 meses, ainda não detalhamos.
  • Camilo: Ok, valeu, boa sorte, depois conversamos.

Esta empresa ainda existe? Não. Eles tinham um monte de planos de negócios, com as palavras de moda, com planejamento financeiro com faturamento exponencial e cálculos de taxa internas de retorno com uma precisão de dois dígitos e não tinham a miní­ma idéia do que iriam fazer na prática.

Por causa disso que eu não me supreendo com esta pesquisa que o Guy coloca no site dele. Um estudo realizado em uma faculdade americana (Babson College) analisou 161 negócios que foram iniciados por ex-alunos. Não existiu diferença estatística no sucesso dos que iniciaram com um plano de negócios e sem um plano de negócios. A conclusão é que caso o empreendedor não precise levantar dinheiro de investidores, não existe a necessidade de escrever um plano de negócios detalhado.

Com isso devemos jogar fora os planos de negócios? Não! A questão é o fetiche (e o mercado…) em torno disso que leva os empreendedores a focarem no plano de negócios no lugar de se focar no produto, mas isso não tira a necessidade de analisar o mercado, planejar os próximos passos, ter a visão de onde se quer chegar e comunicar para a equipe o caminho a ser pecorrido. Veja este texto de Guy sobre plano de negócios e leia o manifesto The Art of Start. Em resumo:

  • Perfect your pitch, then write your plan.
  • Use the business-plan exercise as a way to get your team on the same page.
  • Keep it short: ten to twenty pages.
  • Spend no more than two weeks writing it.
  • Don’t get obsessed with with details in your financial forecast because it should be one page long

Balanced Scorecard, Métricas de Software, PNQ, ISO, CMM. Voc acredita?

Livro Metricas e Gerencia de PessoasMeasuring and Managing Performance in Organizations é um dos melhores livros que já li e deveria ser obrigatório para quem pensa, trabalha ou se relaciona com qualquer um dos assuntos acima. Oriundo de uma tese de doutorado premiada da Carnegie Mellon (berço do CMM) o livro cria um modelo simples com três participantes. Um chefe, um empregado e um cliente. Ele analisa o empregado que realiza um trabalho composto de várias atividades. Algumas são fáceis de serem medidas, outras não. O melhor resultado para o cliente é obtido com uma combinação destas atividades. No caso do chefe medir algumas destas atividades e não medir outras, ocorre uma disfunção, pois o empregado vai privilegiar a atividade que é medida, ignorando ou relegando as outras atividades, neste caso, apesar das mátricas estarem indicando um mar de rosas, o resultado final para o cliente não está. Ocorreu uma disfunção.Normalmente a resposta simplória para lidar com este problema, é criar um novo conjunto de medidas que monitorem todas as atividades. O autor mostra de forma repetitiva a quase impossibilidade de se alcançar este objetivo para trabalhadores criativos. As atividades não são repetitivas e fáceis de serem medidas. Aliás, boa parte do nosso fetiche por medidas é originário da nossa herança do modelo industrial que o trabalho é dividido no formato de Taylor. Taylor dividia o trabalho em pequenas partes que pudessem ser medidas e otimizadas. Funciona no caso dele pois o trabalho é repetitivo, mas alguem acha que o trabalho de design é repetitivo? Como medi-lo?

O autor não invalida completamente o benefício das medidas, mas ele discute largamente a questão se a medida é para gerar informação ou motivação. No primeiro caso, existem chances de sucesso. No segundo, o sistema sempre tenderá a ser burlado.

Um outro problema que pode ocorrer com a utilização de medidas motivacionais e a utilização de remuneração baseada nestas medidas. Um empregado que é motivado intrisicamente (o melhor tipo) quando submetido a um sistema de medida, pode quebrar a boa relação dele com a empresa e passa a ficar atento somente ao quadro de indicadores. Caso o quadro de indicadores não capture todas as facetas do trabalho de forma perfeita, estamos no inicio de um processo de disfunção. Você vai ter sorte se os seus empregados não se submeterem as suas medidas que podem ser estúpidas. (veja o caso no desenvolvimento do Macintosh e do WindowsMicrosoft programmers also became frustrated with IBM’s bureacracy and its use of lines of code to measure programmer productivity”). Não dê risada, o LoC do passado pode ser o nosso Ponto de Função de hoje.

O que ocorre com isso? Os melhores funcionários que são motivados internamente, no momento que você submete um sistema de medidas motivacionais, ele se desmotiva. Os funcionários medianos estarão sobre a pressão do seu sistema e vão tentar burla-lo de forma sistemática.

O autor continua a discussão passando por várias facetas. Ele não condena completamente os sistemas de medidas e discute como tentar implementá-los de forma eficiente, mas ele bate muito duro na dificuldade inerente deste processo. Um ponto interessante é a questão de utilizar um sistema puramente informacional que ele defende de forma sistemática. Neste caso as pessoas teriam confiança na organização e não burlariam o sistema de métricas. O autor entrevista uma série de pesquisadores da indústria e da academia sobre métricas de software. Ele utiliza a área de métricas de software para ilustrar o trabalho, pois é uma área que é complicada de se medir o resultado do trabalho e mesmo assim é amplamente estudada. Sobre o uso dos dados para gerar informação, sem gerar uma caça as bruxas o De Marco fala:

“It could be like the end of the Weimar Republic: The Weimar Republic had collected all kinds of data about names, addresses, and religions of people. Theu knew all the Jews were, and the census data was put to use by the Nazis.”

Ou seja como evitar que os dados coletados sejam utilizados para uma caça a bruxas? Ele no livro comenta de um caso de um sistema informacional que estava funcionando perfeitamente até a chegada de um vice-presidente na sala em que ficavam os gráficos. O vice-presidente achou aquilo tudo muito interessante e anotou alguns comentários. Depois deste dia o sistema foi por agua abaixo.

Um dos capítulos é chamado de The Measurements Disease ele analisa prêmios e programas como o Malcom Bridge (o nosso PNQ), ISO 9000 e CMM. O tí­tulo do capítulo já revela o que ele acha destes programas.

Ele tambêm tem um capítulo dedicado ao cinismo das medidas. Ele elabora um raciocí­nio que em muitas organizações as medidas já são realizadas de forma que proteja a própria gerência e assim se perpetuam estas pessoas.

Finalmente quando ele entrevista os oito experts da área de métricas de software acontece um padrão interessante. Ele divide os entrevistados em dois grupos. De um lado está o grupo da indústria, do outro lado o grupo da academia e de consultores. O grupo da indústria concorda amplamente com o modelo que ele propôs e as disfunçõees causadas por programas de medidas ao contrário do grupo de consultores que discorda do modelo e acha que medidas somente causam disfunções se mal implementadas. Somente um consultor concordou com o modelo dele. Em suma. O pessoal da indústria sofre na pele os sistemas que implementam. Os consultores implementam o sistema em um lugar e partem para a próxima. Em quem você confia mais? Ou parafreseando o Alan Greenspan quando discutia com algumas pessoas: “Se eu conseguisse convencê-lo de que seus argumentos estão errados, você teria condições de, no atual emprego, mudar de opinião?” (ele nunca perguntou isso, mas já teve vontade, citando nominalmente o Craig Barret, da Intel, sobre a forma de contabilizar opções e o premier da China, Li Peng, sobre capitalismo x comunismo. Será que um consultor pode mudar de opinião considerando o atual emprego?)

Finalizando. Não nos esqueçamos da frase do Churchill. “It has been said that democracy is the worst form of government except all the others that have been tried.” Ou seja, métricas estão aí­ para ficar, não conseguimos inventar nada melhor, é necessário medir o que é feito. A única questão: não criar um fetiche por estes números e entender que implementar um sistema de medidas é intrisicamente difícil. Como prêmio para quem chegou até aqui neste longo post, eu deixo o último capítulo do livro, são somente 3 páginas (1.3Mb).  A Difficult But Solvable Problem