Superfície Reflexiva

Amanhã entregamos a primeira versão de um aplicativo que desenvolvemos em .NET e Flex. O objetivo dessa aplicação é complementar um ambiente existente de educação à distância com a possibilidade de dar aulas em tempo real usando vídeo e áudio. Além desses recursos básicos, a aplicação suporta um série de outros recursos que passam por apresentações, enquetes, avaliações completas e gravação das sessões enquanto acontecem.

O interessante é que, apesar da preferência do cliente por tecnologias da Microsoft, o Flex foi escolhido ao invés do Silverlight. O motivo primário foi a estabilidade do primeiro em termos de API. Enquanto o Silverlight ainda está mudando bastante, o Flex já se encontra em uma posição mais estável com um servidor de aplicações muito bem capacitado.

Como esperávamos, dos nossos testes anteriores, o desenvolvimento em Flex foi bem simples e sem muitas surpresas. Tirando a parte de gravação, que levou um pouco mais tempo de pesquisa, a criação das demais funcionalidades foi linear e exatamente dentro do cronograma. Vídeo e áudio estavam funcionando já na primeira semana de desenvolvimento suportando a carga necessária (dezenas de usuários em uma única sessão).

Da mesma forma, a comunicação entre o Flex e o .NET se provou extremamente simples envolvendo pouco mais do que a criação de alguns protocolos REST simples entre os dois pontos da aplicação. Não precisamos nem mesmo de usar alguma camada mais pesada já que as necessidades da aplicação, sendo intermediada pelo FMS, eram bem tranqüilas.

Com um projeto pronto, já temos outros clientes se interessando pela tecnologia. Os recursos citados acima estão sendo desenvolvidos de uma forma mais extensiva e mais refinada e isso tem se mostrado um bom ponto de venda. Isso comprova a minha idéia de que Flex e Silverlight podem se converter em algo muito usado em aplicações internas.

No geral, foi um experiência muito boa e esperamos poder usar o Flex também em integração com os outros frameworks que utilizamos. Django provavelmente será o próximo se tudo correr bem.

Só lembrando os interessados, a palestra sobre linguagens de programação que eu vou dar no ciclo de palestras da e-Genial é hoje.

Acabei de ler The Tipping Point, de Malcom Gladwell. Malcolm Gladwell ganhou notoriedade com livros que exploram implicações novas e contra-intuitivas vindas de sociologia e psicologia, e que, por se aplicarem muito bem em contextos de negócios, estão ganhando bastante seguidores.

O título do livro é um termo da sociologia, e faz alusão ao ponto em que um sistema então estável se torna desequilibrado como resultado de pequenas mudanças. Poderia ser traduzido como “ponto de ruptura” ou “ponto de desequilíbrio” e, embora Gladwell não menciona, é também conhecido como “ângulo de repouso”, espelhando-se no fato físico de que um pouco de peso em objeto até então equilibrado pode levá-lo à queda.

Gladwell postula que mudanças sociais ocorrem sempre como resultado de tais pontos de ruptura, sendo iniciados por pequenas mudanças que pesam a balança até que ela se incline em uma direção determinada. Para ele, isso se aplica tanto a epidemias de doenças quanto a epidemiais socias como a adoção de determinados modismos, o sucesso de uma determinada marca ou mesmo aumento e queda de criminalidade dentro da sociedade. O objetivo principal do livro, então, é criar um modo de identificar e eventualmente causar tais epidemias sociais.

O livro apresenta um caso bem persuasivo para essa possibilidade de manipular epidemias, causa um ponto de ruptura. Para isso, o autor se foca em três principais argumentos (traduções livres):

• A Lei do Poucos: poucas pessoas são necessárias para virar a balança; essas pessoas são denominadas conectores, vendedores e especialistas e possuem características especiais que influenciam fortemente as pessoas com as quais tem contato.

• O Fator de Aderência: a mensagem por trás da epidemia social precisa ter algo que causa aderência, que a faça permanecer na mente das pessoas;

• O Poder do Contexto: a mensagem é extremamente suscetível ao contexto, e, em geral, é possível manipular o contexto para acelerar o desequilíbrio.

O livro apresenta os fatores acima em dezenas de exemplos–o que, por sinal, é ao mesmo tempo uma vantagem e uma desvantagens de alguns livros sobre assuntos similares atualmente: os exemplos preenchem muito espaço quando os pontos básicos e necessários podem ser feitos em bem menos páginas. Mesmo assim, a maioria dos exemplos são fascinantes, com destaque especial para os que envolvem ritmos de interação, ou seja, aqueles padrões que adotamos inconscientemente quando estamos conversando com outras pessoas.

Aliás, um dos exemplos que mais me fascinou foi justamente sobre isso: um pesquisador que dividiu um filme de quatro segundos de uma conversa à mesa em suas partes mínimas (as frames de 1/45 de segundo) e passou um ano o meio analisando cada parte até determinar movimentos mínimos coordenados entre as partes da conversa–movimentos que sugeriam uma espécie de dança inconsciente entre as pessoas envolvidas e que explica muito sobre como persuasão e relacionamentos funcionam, entre outros detalhes psicológicos

Tudo isso torna a leitura do livro bem tranqüila e rápida–nunca cansativa–e as idéias apresentadas são suficientemente interessantes para merecer consideração posteriores e eventual aplicação em estratégias. Não que o livro deva ser tomado como uma bíblia; ainda assim, os argumentos são bem elaborados e embasados, fazendo sentido principalmente nos contextos mostrados. E se Gladwell exagera em alguns momentos para forçar o seu ponto–como no final do livro onde ele fala sobre o problema do fumo entre adolescentes–o resultado geral é muito bom.

Como de costume nas resenhas aqui, recomendo a leitura–preferencialmente se você for ler sem considerar o livro um manual. Idéias com certeza vão aparecer, mas ler sem o hype certamente ajuda.

Enquanto (quase) todo mundo está folgando no Carnaval, os “empresários”–popularmente conhecidos como autônomos sem dinheiro–como eu estão correndo para longe do prejuízo tentando terminar projetos.

Eu me consolo apenas com o fato de que não preciso bater ponto mais.

Convergência de aplicações distribuídas via SOA é uma das grandes “tendências” atuais. É claro que, para onde quer que se olhe, há mais problemas a serem resolvidos do que soluções, mas o mercado está seguindo uma direção razoavelmente consistente.

Hoje, durante uma conversa com um amigo no almoço, o assunto se desviou para aplicações desse tipo, aplicações que a empresa na qual ele trabalha está percebendo agora nessa arena. É sempre interessante conversar com uma pessoa de uma área completamente diferente–no caso dele, engenharia–porque a perspectiva distinta serve para balancear a sua própria. Trabalhando com Internet, como é o meu caso, tecnologias como Google Apps for Your Domains, S3, EC2 e muitas outras similares são conceitos naturais e, de certa forma, aceitas como naturalmente vantajosas a longo prazo.

A minha percepção atual está bem centrada na confiabilidade de tais serviços, não em relação ao uptime necessariamente, mas em relação a segurança a longo termo de informações necessariamente distribuídas. E minhas conversas tendem a confirmar esse ponto. É quase como se a indústria de informática tivesse um blind spot em relação a esse tipo de problema.

Quase no final da conversa, ele me perguntou qual o timeframe provável para aceitação de aplicações SOA de um modo geral. Eu ri, brincando que era uma resposta impossível sem uma máquina do tempo.

Depois, pensando no assunto, me ocorreu que provavelmente existe um ponto definido para a aceitação de tais aplicações. O principal problema por trás dessas aplicações está focada na disponibilidade de uma rota de acesso, que é mais importante do que banda–até porque a maioria dessas aplicações são naturalmente leves. Sendo assim, esse problema teria que ser resolvido por algo intrinsecamente ubíqüo.

Não vou arriscar uma previsão, mas acho que a chave para a aceitação dessas aplicações–seja daquelas hospedadas em server farms ou daquelas rodando nos próprios servidores de uma empresa–está na convergência da telefonia celular.

Não acredito que estamos a muitos anos da transformação definitiva do celular em outro aparelho que se tornará a ferramenta computacional básica de uma pessoa. É uma evolução que está em seu começo ainda, mas é certa. Um aparelho assim seria uma estação de trabalho permanente, um centro de mídia, e por aí vai. Lembra alguma coisa?

Somando isso com a expansão das redes já existentes, o maior problema do SOA fica resolvido. Reforçando o ponto, não é uma solução existente em termos gerais, mas já sabemos como a nossa indústria anda. É realmente só uma questão de tempo.

Faz sentido? Eu acho que sim.

Recebi uma notinha do meu contador hoje informando que a contribuição sindical, que eu pensava ser opcional, na verdade é obrigatória, com base em uma lei qualquer. Tristeza. Eu nunca recebi um folheto que fosse do sindicato–ou qualquer outra coisa para falar a verdade–e ainda sou obrigado a contribuir.

Eu até entendo a necessidade que as pessoas tem de criar organizações para controlar aspectos mais tortuosos de uma determinada área profissional. Mas criar uma entidade cujo único sinal de existência é pedir o seu dinheiro anualmente é revoltante.

Começar uma empresa sua é um negócio complicado, com perdão do trocadilho. São tantas coisas preocupando a sua mente que você fica sem saber o que faz primeiro, tanto na questão da organização da empresa em si como no dia-a-dia do trabalho. Passar do mindset de um engenheiro para o mindset de um gerente é um desafio e tanto.

Nos últimos meses, eu venho tentando me adaptar a essa situação, lentamente estabelecendo as bases para o meu negócio. Acho que eu nunca tive um tempo tão apertado em minha vida, parecendo um malabarista que tenta equilibrar as demandas de administração de contas e gerenciamento de projetos.

Mas, a despeito das complicações, eu estou gostando muito da experiência. Existe, por um lado, a necessidade de ficar muito mais atento aos pequenos problemas que surgem diariamente e que demandam uma forte priorização para evitar que as demandas se acumulem, e, por outro lado, a liberdade de tomar suas próprias decisões no que concerne ao rumo dos seus projetos. É um aprendizado contínuo já que a prática da administração de uma empresa, em termos do tipo de problemas que surgem, é qualitativamente diferente da prática da análise de sistemas.

De certa forma, é a mesma diferença entre humanas e exatas. Você não lida com quantidade precisas que podem ser medidas e repetidas de acordo com a necessidade, mas com variáveis dinâmicas que oscilam entre fatores cujo balanço muitas vezes é bem delicado.

Existe também uma certa ironia quando você passa de empregado a patrão. Eu imagino que isso seja comum a todos empregados em qualquer parte do mundo e em qualquer período histórico, mas o fato é que estamos sempre reclamando das condições de trabalho. Algumas vezes com razão e outras vezes não, embora as coisas em que não temos razão acabem sempre mascaradas pelas reclamações válidas. Quando você passa para o outro lado dessa equação é que fica claro como é difícil manter todos os lados satisfeitos. Uma empresa tem tantas necessidades quanto seus funcionários e conciliar as duas coisas requer bastante trabalho.

Por outro lado, é possível ver também quantas decisões simples poderiam ser tomadas que facilitariam a vida dos funcionários com retornos bem interessantes. Como eu já estou precisando de funcionários, eu estou tentando criar um estilo diferente de trabalho que beneficie os funcionários e os mantenha satisfeitos. O objetivo é provar que, algumas vezes, o que vai contra o senso comum empresarial é, na verdade, o melhor caminho. Algumas experiências estão funcionando muito bem.