Para utilizá-la é simples: o usuário só precisa usar óculos 3D, comandos de voz e as mãos para manipular os objetos. Além disso, todo o sistema usa apenas dispositivos de baixo custo, como o Kinect, e não requer o uso de monitores especiais para a exibição da imagem 3D, ficando ao alcance de todos.

Aplicações

O Fusion4D foi desenvolvido como opção de manipulação direta para o atlas anatômico VIDA, do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab). Este atlas é destinado a aulas de anatomia que usam uma grande quantidade de modelos e órgãos reais, o que torna difícil e caro manter os laboratórios. O projeto representa uma alternativa para complementar o estudo através de peças anatômicas e livros dereferência. Existe ainda o potencial para seu uso fora do ambiente do laboratório, permitindo aos estudantes a visualização dos modelos 3D em casa ou em outras situações de ensino a distância.

Além da aplicação no projeto VIDA para ensino da medicina, o Fusion4D poderá ser usado para outras aplicações médicas e educacionais, bem como em jogos, publicidade, engenharia, navegação em ambientes virtuais ou telepresença, entre outras áreas.

Como funciona?

O Fusion4D utiliza imagens 3D anaglifas e um dispositivo Kinect para detecção do esqueleto e captura de voz do usuário.  O usuário interage com o sistema usando comandos de voz em inglês. Tais comandos permitem que se selecione o objeto a ser manipulado e a maneira de interagir com ele.

Comandos

O comando “grab” seleciona um objeto e permite movimentar, rotacionar ou ampliar o objeto com as mãos até que o objeto seja solto pelo comando “release“.

O comando “explode” permite observar o objeto 3D em detalhes; o comando “show label“ mostra uma etiqueta descritiva do objeto manipulado, e o comando “change model“ permite escolher outros modelos disponíveis no sistema.

Finalmente, o comando “time” permite ver como o objeto seria no passado e no futuro movimentando a linha do tempo com uma das mãos. Se o usuário precisar de ajuda sobre o sistema, o comando “help” mostra uma lista de comandos de voz.

Este projeto foi desenvolvido como trabalho de formatura pelos alunos Keila Keiko Matsumura e Roberto Sonnino, formandos da turma de 2011 do Curso Cooperativo de Engenharia de Computação, e orientado pelos professores Dr. Romero Tori (orientador) e Dr. Ricardo Nakamura (coorientador), membros do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab).

Para mais informações do projeto e dos resultados obtidos e trabalhos futuros, acesse o site do Fusion4D.

Você já ouviu falar de sistema de recomendação? Já teve a curiosidade de saber como funciona? Pois, então, prossiga na leitura. Em especial, abordarei o tema utilizando terminologias e dados da rede social Facebook.

Introdução

Você já ouviu falar de sistema de recomendação? Já teve a curiosidade de saber como funciona? Pois, então, prossiga na leitura. Em especial, abordarei o tema utilizando terminologias e dados da rede social Facebook.

Por quê? O Facebook é uma rede social gigantesca e, provavelmente, quase todos os seus amigos possuem uma conta lá.

Alguns sistemas, por exemplo o GiveEmThis.com, propõem a utilização dos dados dos seus amigos para auxiliar a tarefa da compra de presentes. Podemos também citar a Amazon, a qual possui iniciativa que utiliza dados sociais do Facebook para personalização de recomendações (notícia no mashable). Hoje em dia, fala-se muito sobre sistemas de recomendação e, acredito, que você não deva passar um dia sem receber algum tipo de informação de algum sistema do gênero.

No decorrer do artigo, apresentarei, de maneira geral, os conceitos e formas para o entendimento e desenvolvimento de um simples sistema de recomendação de páginas (likes) utilizando os dados dos seus amigos do Facebook. Por simples, quero dizer não serão abordadas formas de como lidar com o fato de os dados serem esparsos; nem com o fato de estarmos mexendo com um grafo, por exemplo, podemos coletar dados do amigo do amigo do amigo; nem mesmo com fato de estarmos em um contexto social (laços de amizade). Nos restringiremos, assim, aos nossos amigos imediatos, ok? Se você entendeu pouco ou nada deste último parágrafo, não tem problema. Se tiver curiosidade, mande um e-mail. Além do mais, neste primeiro artigo, não entrarei em detalhes de como coletar os dados.

Recomendação de páginas (no exemplo, página da banda AC/DC) utilizando likes de amigos

Para quem não conhece a mecânica do Facebook: através dele é possível gostar de páginas, por exemplo, um usuário pode gostar (like) da página de uma banda de rock. Porém, não há a opção negativa, ou seja, não gostar de alguma página explicitamente (dislike). Estes likes criam links entre os usuários e as páginas e podem ser utilizados para tarefas interessantes (além da tratada aqui), por exemplo, para segmentação de mercado. Na nova versão do OpenGraph (que atualmente está em Beta) do Facebook , é possível executar “ações” que ligam usuários às páginas (e outros objetos), por exemplo, a Ana comprou o CD do ACDC. Mas isso é tema para artigo futuro.

Filtragem Colaborativa

Imagine, agora, uma situação em que você esteja conversando com um amigo. Você sabe que ele gosta de seriados, filmes e bandas com as quais você também se identifica, ou seja, os seus gostos são similares. Nesta conversa, ele recomenda um filme que ele gosta, mas que você não conhece. Assim, por conhecer os gostos dele, você fica curioso em assistir ao filme. Este processo se repete diariamente em nossas vidas. Agora imagine o caso em que, ao invés de um amigo, estamos lidando com um grupo de amigos, cujos gostos são conhecidos, alguns mais similares e outros menos. Como poderemos filtrar recomendações destes amigos?

De maneira geral, para um simples sistema de recomendação que lide com objetos e usuários, os laços de amizade não importam. Neste artigo, também iremos ignorar os laços de amizade. Mas adianto que podemos desenvolver sistemas que exploram estes laços para obtenção de melhores recomendações personalizadas.

Podemos abordar o problema com uma técnica que é conhecida, na literatura, por filtragem colaborativa baseada em usuários (tradução livre do inglês user-based collaborative filtering). O termo ilustra o fato de vários usuários estarem colaborando para que o sistema filtre uma recomendação para você. Neste caso, para filtrar recomendações, o sistema explora a similaridade entre usuários utilizando as ligações entre estes e os objetos. Existe, também, o caso em que a filtragem é baseada nos objetos (item-based collaborative filtering), no qual, o sistema explora a similaridade entre os objetos utilizando as ligações entre usuários e objetos. Detalhes, vantagens e desvantagens das duas abordagens podem ser explorados em outro artigo.

Definição do problema e modelagem dos dados

Na definição do problema, temos como objetivo desenvolver um recomendador de gostos (possíveis novas ligações entre você e uma página recomendada) baseado em gostos de outros usuários (ligações já existentes). A partir do Facebook, podemos obter dados dos usuários (você e amigos), das páginas e das ligações entre eles.

Esses dados podem ser representados em uma matriz, na qual as linhas representam os usuários e as colunas representam os objetos. Nas células da matriz, 1 indica que o usuário (linha) desta célula gosta do objeto (coluna), e 0 indica que o usuário não conhece o objeto ou que não gosta deste (discutiremos isto novamente).

Matriz de Dados - exemplo com 5 usuários e 5 páginas, os testes foram feitos com 5 usuários e 250 páginas

Cálculo de similaridades

Agora, o recomendador deve quantificar as similaridades entre você e seus amigos. Por exemplo, imagine que você goste de 5 páginas, sua amiga Ana goste de 10, que vocês gostem de 3 em comum (interseção) e que, juntando todas as páginas que você e Ana gostem, temos 12 páginas (união). Podemos expressar a similaridade entre vocês dois pela razão entre o total de páginas em comum pelo total de páginas juntas, ou seja, a quantificação da similaridade seria de 3/12 (0.25). Se você conhece notação de conjuntos, fica como exercício traduzir o para ela.

Existem diversas formas de calcular a similaridade entre duas entidades. No caso, o coeficiente descrito é conhecido por coeficiente de similaridade de Jaccard. Podemos, por exemplo, calcular esse coeficiente utilizando distância euclidiana, correlação de Pearson, entre outras formas.

Gerando recomendações

Agora que temos uma maneira de quantificar as similaridades entre você e os seus amigos. Podemos, por curiosidade, obter uma lista dos amigos do usuário Alvo (usuário de testes) ordenada pelo coeficiente de similaridade utilizado. O usuário criado para os testes deste artigo possui 4 amigos (visualizar matriz de dados).

Lista de amigos ordenados pelo coeficiente de similaridade (neste caso, coeficiente de Jaccard)

Observe os valores dos coeficientes. O valor final está no invervalo [0,1]. Os valores são baixos pois o total de elementos do conjunto de gostos derivados da união de duas pessoas é muito grande. O total de páginas que gostamos pode ser pouco comparado ao total existente (a matriz resultante da representação dos dados é esparsa). Por exemplo, Bob pode gostar de 206 páginas, enquanto você gosta de apenas 6, todas em comum com Bob. Então, o valor da similaridade calculado será baixo, mas como estamos calculando os valores em relação a você, o valor será alto para você. Para Bob, talvez este valor seja baixo mesmo, ou seja, talvez exista uma amiga Carla que goste de 30 objetos em comum com Bob, enquanto você gosta de apenas 6 (repare que o apenas é relativo). O zero do coeficiente indica que não há gostos em comum.

Podemos, de imediato, dar uma olhada nos gostos do amigo que ficou em primeiro lugar e escolher aleatoriamente algo que não conhecemos. Mas, o recomendador pode fazer melhor. O resultado final pode ser obtido utilizando-se uma média ponderada das páginas que ainda não conhecemos utilizando os coeficientes de similaridade dos nossos amigos como pesos. Os valores obtidos podem ser interpretados como a probabilidade de nós gostarmos do objeto em questão.

Exemplo de cálculo da média ponderada para o usuário Alvo e página JovemNerd. Notações: sim(W,Z) representa o coeficiente de similaridade entre W e Z; Like(X, Y), expressa se X gosta da página Y.

Para efetuar a média ponderada, utilizaremos tantos os 0s quanto os 1s associados a uma página. No like do Facebook, a escala encontrada é limitada, 0 ou 1, e nela, o valor de 0 não significa o contrário do valor 1, ou seja, 1 significa que gostamos, mas 0 pode significar que não conhecemos ou que não gostamos da página. Mesmo assim, o recomendador pode utilizar os 0s para amortizar a recomendação final.

Imagine que sua amiga Ana goste de uma página, que a similaridade entre vocês seja 0,1, que seu amigo Bob não goste desta página e que a similaridade entre vocês seja 0,8. Se não levarmos em consideração o 0 do Bob na média ponderada, o recomendador retornará 1 para a página em questão. Na verdade, o recomendador retornará 1 para todas as página que algum amigo seu goste e que você não conheça, pense um pouco. Se levarmos em consideração o 0 do Bob, que é muito similar a você, o recomendador amortizará o valor e retornará 0,1/0,9, aproximadamente 0,11, um valor baixo que expressa o fato de que se a Ana gosta e vocês não são tão similares, talvez você não goste mesmo.

Para a conta final, o recomendador calcula os coeficientes de similaridade entre você e seus amigos e armazena os valores. Então, para todos os 0s da sua linha na matriz (páginas que você não conheça), o recomendador realiza a média ponderada dos seus amigos: soma as similaridades dos amigos que gostam da página, divide pela soma total das similaridades e armazena onde encontrou o 0. Ao final, teremos valores inferidos pelo recomendador que expressam, baseando-se nos dados dos seus amigos, a probabilidade de vocês gostar das páginas que estavam com 0s.

As 5 primeiras páginas recomendadas.

Cálculo para a página JovemNerd

Considerações

A abordagem que utilizamos é simples o bastante para que possamos entender os conceitos envolvidos e o que acontece por debaixo dos panos. Por ser simples, não recomendo a implementação desta abordagem em produção. Ela possui alguns problemas.

A abordagem não é escalável. Imagine que o seu sistema possua 100 usuários com 300 amigos cada, assim, o recomendador terá que fazer as contas explicadas usuário por usuário e terá que fazer novamente assim que houver alguma mudança.

O recomendador pode ser alvo fácil de ataques. Imagine que criemos um usuário David, fazemos amizade com o usuário que queremos atacar e fazemos com que David goste de todas as páginas que o nosso usuário alvo goste, assim, o coeficiente de similaridade será alto. Em seguida, David é programado para gostar de uma página que temos interesse que o usuário alvo goste. Pronto, o recomendador colocará esta página em uma posição alta na lista dada a similaridade entre os dois usuários.

O que acontece com usuários que não gostaram de nada ainda? Todos os coeficientes de similaridades serão nulos pois não possuem gostos em comum com ninguém. Na literatura, este problema é conhecido como the cold start problem.

Além do mais, o recomendador em questão possui baixa serendipidade (do inglês serendipity), talvez até nula, e, assim, caminharíamos aos poucos para um monoculturalismo. Nos próximos artigos poderemos entrar em detalhes de soluções que lidem com esses problemas.

Introdução

Logo do Sistema

Conceitos:

• Business Process Management (BPM)

BPM é uma prática de desenvolvimento, execução, análise de desempenho e simulação de Processos de Negócios para trabalhar no na continua otimização e ciclos de vida desses processos.

• Service-Oriented Architecture (SOA)

Uma prática de desenvolvimento de software que emprega disciplinas e linguagens de modelagem para fornecer soluções táticas e estratégicas aos problemas das empresas. Ela defende uma visão total da analise, desenho e arquitetura de todas as entidades organizacionais do software, concebendo-as como recursos de serviços-orientados, isto é, serviços.

Exemplo de Processos Aliados a Serviços

• Processo de Lançamento de Celulares:

Metodologia

• Estudo do Processo

Exemplo de Processo Modelado em Linguagem EPC

• Concepção do Projeto de Software

• Implementação do Projeto

Implementação com a ferramenta webMethods

• Testes e Análise de Performance

• Monitoramento e Manutenção do Processo

Dashboard de Monitoramento do Processo

Resultados Esperados

Parcerias

Parceiros

O cenário vislumbrado para a aplicação publicitária é o de uma vitrine de shopping, na qual as reações expressas pelas características faciais dos passantes são registradas e avaliadas. A partir desta análise, é possível verificar como o design da vitrine e a maneira de exposição das mercadorias afetam as reações dos consumidores, tanto positivamente como negativamente. Constituindo assim uma maneira de se avaliar e comparar os impactos alcançados com diferentes estratégias.

O sistema realiza a aquisição e processamento de uma sequência de imagens obtidas através de uma webcam e possibilita, através da produção de gráficos, a exibição de informações relevantes a um usuário da área de publicidade e propaganda que deseje medir a eficácia de uma campanha publicitária.

Apesar de a ideia do nosso projeto ser bastante simples, o título do projeto ser um pouco obscuro para quem não está familiarizado com estes termos. Vamos começar explicando o título e as coisas ficarão mais claras.

O que é…

… Veículo aéreo não-tripulado?

Um Veículo Aéreo Não-Tripulado, também conhecido pela abreviação VANT, é qualquer tipo de aeronave (como aviões, balões, helicópteros) que não precise de um piloto para ser guiada. No nosso projeto, utilizamos um dirigível cheio de gás hélio para representar o VANT.

… Mensagem CPDLC?

O CPDLC (Controller Pilot Data Link Communications) é uma aplicação utilizada para a comunicação entre os controladores de voo, localizados nas torres de comando, e os pilotos, localizados na aeronave tripulada. Uma mensagem CPDLC é uma mensagem de texto que segue o formato definido na especificação da Organização Internacional de Aviação Civil (ICAO – International Civil Aviation Organization). O piloto recebe e envia mensagens CPDLC utilizando um dispositivo denominado MCDU.

… Controle?

No contexto do nosso projeto, controle significa o envio de comandos, que poderão ser aceitos ou recusados pela aeronave.

O projeto

Agora sim: o nosso projeto trata de controlar um balão a partir do envio de comandos, como virar à direita, subir ou descer e alterar a velocidade, utilizando um protocolo de comunicação já existente e já utilizado na Aeronáutica hoje. Comportando-se como um VANT autônomo, o balão deve tomar decisões sobre estes comandos recebidos, decidindo se pode ou não executá-los, com base em variáveis medidas de um conjunto de sensores embarcados.

Motivação

A ideia do nosso projeto é que ele sirva como uma prova de conceito, ou seja, que ele mostre que é possível, controlar um VANT à distância, apenas através da troca de mensagens CPDLC e que, ainda assim, o voo realizado seja tão ou mais seguro quanto ele seria se existisse um piloto a bordo.

Um dos motivos para isso é que existem diversas situações em que a presença do piloto restringe a duração do voo. Um exemplo disso são voos de monitoramento de áreas de fronteira. Estes voos normalmente são utilizados para coleta de imagens, e não existe uma carga sendo transportada ou um destino específico. É interessante, portanto, não depender de um piloto, que pode ficar exaurido fisica e psicologicamente em um voo muito longo.

Outro motivo é que existem muitos acidentes aéreos causados por falha humana. Um piloto, por ser um ser humano, naturalmente está sujeito a cometer erros, mais ainda se não tiver um treinamento adequado. Se for possível substituí-lo por um sistema computacional devidamente projetado, implementado e testado, o número de acidentes será reduzido, tornando o espaço aéreo um lugar mais seguro.

Implementação

O sistema pode ser dividido em três módulos, mostrados na figura abaixo:

Diagrama de blocos do sistema de controle implementado

ACARS

O ACARS (Aircraft Communications Addressing and Reporting System) é um simulador de código aberto que foi utilizado no projeto, nós fizemos apenas pequenas alterações no código-fonte. O simulador completo que foi utilizado é composto por dois submódulos. O primeiro é o servidor ATC, cuja função é centralizar a comunicação entre o controlador e o piloto, registrando aeronaves e transmitindo para o destinatário (controlador ou piloto) as mensagens que são recebidas. O segundo submódulo possui, entre outras coisas, uma interface, mostrada abaixo, que permite o envio de mensagens CPDLC para as aeronaves – no nosso caso, o balão.

Interface para criação de mensagens no padrão CPDLC

Módulo Python

Idealmente, as mensagens CPDLC seriam enviadas diretamente do servidor do ACARS para o balão. Contudo, o microcontrolador utilizado no projeto (Atmega128 usado no Arduino Uno) possui severas restrições de processamento, tendo apenas 32KB disponíveis para o código-fonte e 1KB para a área de dados. Assim, foi introduzido um módulo que representa parte do sistema que normalmente ficaria na aeronave, mas que roda em um computador em terra. Este subsistema é responsável por receber mensagens CPDLC, traduzi-las para mensagens MBCP (My Blimp Control Protocol) e então transmiti-las ao balão. O MBCP é um protocolo bastante simples desenvolvido especificamente para o projeto.

Abaixo é mostrada a interface que foi desenvolvida para este módulo: ela imita a aparência de um MCDU, mostrando mensagens recebidas pela aeronave (denominadas de uplink, em laranja) e enviadas (de downlink, em verde).

Interface do módulo Python, emulando um MCDU

Módulo embarcado

Finalmente, temos o módulo embarcado. Este é composto pelo programa que roda no Arduino assim como pelos circuitos eletrônicos auxiliares que permitem a leitura dos sensores, o controle dos motores e o envio/recebimento de mensagens MBCP via rádio. Utilizando as leituras dos sensores, o balão consegue inferir qual o seu estado com relação ao ambiente em que se encontra, tomando decisões sobre a possibilidade de execução de um comando, e rejeitando aqueles que puderem colocá-lo em uma situação de risco.

A figura abaixo mostra a gôndola que é presa ao balão, com os três motores à mostra, assim como os três sensores infravermelhos, utilizados para detectar a distância de obstáculos frontais e laterais.

Gôndola que é presa ao balão, com sensores e motores visíveis

Dentro desta gôndola ficam os circuitos descritos acima, e mostrados na figura abaixo. Da esquerda para a direita, temos:

• Arduino: contém o microcontrolador que permite a execução da lógica de controle do balão.
• Placa de cirtuito impresso: projetada e desenvolvida especialmente para o projeto. As três placas menores (duas vermelhas e uma verde) são sensores inerciais – uma IMU (Inertial Movement Unit), um acelerômetro e uma bússola digital.
• Transceptor: permite envio e recebimento de mensagens de rádio.

Circuitos eletrônicos embarcados no balão

Esta foi uma brevíssima descrição do projeto. Quem estiver interessado em conhecer os detalhes pode entrar em contato ou fazer o download da monografia, que em breve estará disponível.

E não percam a demonstração prática, que acontecerá no dia 14 de dezembro, no Galpão da Administração da Poli!

Dennis Ritchie é um pouco (ha-ha) menos conhecido que o Steve Jobs, mas merece uma página de destaque tão grande quanto Steve.

Ritchie é reconhecido por duas grandes criações, que vivem até hoje e revolucionaram a computação. A linguagem de programação C e o sistema operacional UNIX.

Vencedor do prêmio Turing em 1983 pelo seu trabalho com o UNIX. Sistema esse que continua sendo base para uma parte dos sistemas operacionais utilizados nos dias de hoje ( incluindo o MacOS do outro homenageado do mês ).

Tudo que posso dizer é que ele mudou a computação e agradecer por deixar um legado tão importante!

Valeu Ritchie! Break;

Alguns fatores que definem a qualidade da informação são: Confiabilidade, Confidencialidade, e Disponibilidade. Esse último parece ser muito simples de compreender e ainda mais simples de se confundir.

Disponibilidade é: A qualidade do que se pode fazer uso, segundo o dicionário. Ou ainda podemos enunciar disponibilidade como é utilizada por muitos estudiosos de sistemas: A probabilidade de um sistema estar funcionando corretamente e disponível para desempenhar suas funções, num dado instante de tempo t.

A disponibilidade porém não é estática, e pode variar entre sistemas e até mesmo dentro de um sistema. A queda da rede por exemplo, gera um óbvio problema de disponibilidade da informação e perturba a disponibilidade como um todo. A disponibilidade também é afetada por um outro fator que determina a qualidade da informação: Confidencialidade.

Esse fator reduz a disponibilidade em sistemas que usam amplamente interface com humanos porque afeta o sentimento das pessoas envolvidas.

Metaforizando um pouco aqui vamos analisar a disponibilidade de um sistema que será compreendido imediatamente pela metade masculina dos hipotéticos leitores (a metade feminina, se existente, por favor perdoe o exemplo). Vamos falar sobre o sanitário masculino!

O sanitário masculino possui um número N de acessos para alíviar urgências de natureza líquida, e portanto a disponibilidade teórica de N mictórios. Porém como todos os leitores hipotéticos masculinos sabem, a realidade é bem diferente dessa teoria.

A busca para reduzir os momentos constrangedores, nos leva a utilizar – mesmo que inconscientemente – o International Choice of Urinal Protocol. Os cálculos mostrados no link nos mostram que o grau máximo de disponibilidade de um sanitário com N mictórios – sem constrangimento – é 2N/3 (edit: para o caso de N=1, teremos disponibilidade de 100%, assumam N>1. Grato.).

A perda de disponibilidade do sistema de 33% não é visível no sistema até o momento em que colocamos o mesmo em uso. Somente com a interação do sistema com humanos podemos perceber os problemas na disponibilidade.

O sistema deve considerar a forma como ele será utilizado pelas pessoas, a forma como as pessoas utilizam outros sistemas, os sentimentos da pessoa ao utilizar o seu sistema. É necessário deixar a pessoa a vontade ao acessar o seu sistema, isso faz parte da disponibilidade.

Simplesmente o aumento das formas de acesso a informação, pode não permitir o aumento na disponibilidade (faça os teste com o sanitários com 5, 6 e 7 mictórios). Deve ser prioridade de quem está desenvolvendo o sistema se preocupar com a disponibilidade da informação.

E encerrando o exemplo do sanitário, fica a máxima: sempre se preocupem com a visualização da “informação” pelos seus usuários.

Outro dia, no almoço, eu tive uma pequena epifania. Eu também tinha um garfo de churrasco, mas isso é uma outra história. Em qualquer evento, algo veio a claridade que tinha me incomodado profundamente por algum tempo.

Nos últimos anos, a indústria de software se tornou cada vez mais focada no processo e métricas como uma forma de garatir códigos de “qualidade”. Se você seguisse todas as melhores práticas agora, você faria:

• TDD completo, escrevendo seus testes antes de implementar o código.

• Requerer uma porcentagem arbitrária de código checada antes de fazer um check-in.

• Revisar o código completamente em todos os check-ins.

• Usar ferramentas como o Coverity ou Sonar para gerar números de complexidade de códigos e requerer refatoração por parte dos desenvolvedores quando o código estiver demasiadamente complexo.

Adicionalmente, se sua companhia tem bebido Tang sabor Scrum, vocês também teria que gastar seus dias com:

• Geração de cabeçalhos, histórias e tarefas.

• Limpar as histórias antes de cada sprint.

• Aturar seções de planejamento.

• Controlar seu tempo para gerar gráficos para a gerência.

Resumindo, você estará usando boa parte do seu tempo com o processo, e cada vez menos tempo realmente programando a aplicação. Eu trabalhei em algus projetos onde os casos de testes duravam duas ou três vezes mais que programar o código em si, ou onde a necessidade de marretar os testes de unidades reduziram a legibilidade do código. Eu também vi exemplos de desenvolvedores tendo que enganar as ferramentas para atingir metas de quantidades de linhas e complexidade de códigos. A recursão subsequente faz com que isso seja progressivamente pior para o programador passional que escreve um código ótimo, mas o processo mata a paixão. Programadores desinteressados escrevem códigos ruins, códigos ruins fazem com que a gerência adicione mais processos na tentativa de “fazer” com que programadores escrevam bons códigos. E isso somente piora a moral.

Agora, eu certamente não estou advogando para uma abordagem velho-oeste onde nada é testado, e os desenvolvedores programam o que querem ignorando as agendas, etc. Mas a aplicação cega de processos de melhores práticasatravés de todo o desenvolvimento está tornando o que deveria ser um processo criativo em um relatório financeiro com gráficos com um toque de prisão. Enquanto cada um destes bambolês parece bom isoladamentes (exceto talvez o Scrum…), fazer os desenvolvedores passarem por todos eles vai desmoralizar até o mais apaixonado dos geeks.

Eu não tenho a bala mágica aqui, mas as companhias precisam começar a aceitar que existe uma diferença qualitativa entre os desenvolvedores. Fazer com que todos eles usem arados de mesmo peso para garantir que nenhum deles cometa erros é prejudicial para a moral e eficiencia como um todo. Agora, isso pode soar um pouco arrogante: “Eu sou um desenvolvedor experiente, eu não preciso de nenhum desses recém-criadas práticas para fazer bom código.” Mas, por exemplo, talvez desenvolvedores júniores (ou especializados) devessem escrever testes de unidades, deixando os desenvolvedores mais calejados livres para se concentrar na real implementação da aplicação. Talvez você não precise micro-gerenciar eles com seus updates diários do VersionOne para ter certeza que eles estão comprometidos com o sprint.

Talvez uma olhadinha no código seja preferível a um processo de revisão formal.

E um segredo, se voce está dizendo que voce está praticando desenvolvimento ágil, então pratique um desenvolvimento ágil!!! Um projeto onde você decidiu antes de iniciar o ciclo do produto as características que devem ter no produto, a data em que deve ser entregue, e os recursos necessários é um projeto cascata. Usar termos como “histórias” e “sprints” apenas inserem uma casca ágil quebradiça, e é loucura pensar qualquer coisa além disso. E francamente, isso é o que levou a toda a mentalidade Scrum/Burn Down Charts, porque as equipes de desenvolvimento não tema  flexibilidade para “entregar o que está pronto, quando estiver pronto.”

A não ser que os problemas que eu estou falando sejam atacados, eu temo que o ciclo negativo processo/paixão irá continuar a dragar desenvolvedores engajados em um pântano de reuniões e jogos de métricas.

Traduzido daqui.

A Arquitetura Orientada a Serviços, ou SOA (do inglês Service-oriented Architecture), é um conjunto de práticas que definem um tipo de arquitetura de software. Uma implantação de uma SOA em um ambiente corporativo pode resultar num impacto muito grande no modo de encarar o gerenciamento de TI e processos de negócio.

SOA tem-se mostrado uma alternativa muito eficiente para aumentar flexibilidade e agilidade da estrutura de TI de uma empresa. Como, hoje em dia, o valor de negócio de grande parte das corporações está intimamente atrelado à eficiência de sua área de TI, SOA tem sido cada vez mais vista como uma melhoria de eficiência de negócios. Com base nestas características, uma SOA pode ser enxergada por diversos prismas dentro de uma organização: por gerentes de negócio como uma vantagem estratégica, por administradores de TI como uma melhoria de organização estrutural, por desenvolvedores como um conjunto de padronizações, etc.

Antes de explicar melhor este ponto,

O que é SOA?

SOA pode ser entendida como um conjunto de práticas de software que se dispõe conferir as seguintes características a uma arquitetura de software:

• Descrever as funcionalidades de negócio por meio de serviços
• Promover modularidade, separando cada componente de software
• Baixo acomplamento entre aplicações
• Encapsulamento
• Composição
• Reuso

Para atingir esses objetivos, uma SOA segue as seguintes práticas:

• Expor em um meio comum as funcionalidades das aplicações existentes (e das que deverão ser desenvolvidas) como serviços (normalmente Web Services);
• Essa exposição deve ocorrer por meio de interfaces bem definidas, descritas por um protocolo comum (normalmente WSDL) especificando as operações, os dados de entrada e os dados de saída;
• O meio comum de comunicação entre esses serviços deve incorporar um protocolo de comunicação também comum (normalmente uma rede, com protocolo SOAP sobre HTTP ou SOAP sobre JMS).

Expondo as aplicações por meio de interfaces bem definidas em uma rede de computadores que identifique cada funcionalidade como um serviço, promove-se o encapsulamento. Pois assim, os detalhes de implementação de cada serviço (como a linguagem em que foi escrito ou sistema operacional em que ele funciona) não necessitam conhecimento por parte de seus consumidores. Mais ainda, os serviços devem ser reutilizáveis e associáveis.

Por meio dessa estrutura, o negócio pode aproveitar mais dos resultados de seu software, preocupando-se menos com os detalhes de seu funcionamento. Este panorama forma uma Arquitetura Orientada a Serviços.

Os significados de se adotar uma SOA

Quando uma organização estabelece uma SOA, ela está muito mais apta a se adaptar. O modo em que SOA é estabelecida propicia baixo custo – temporal, operacional e financeiro – de atualização, já que os serviços são independentes. Modificar um serviço, ou acrescentar um novo, não implica modificações nos demais. Essa característica faz com que seja fácil adaptar-se às novas regras e necessidades do negócio.

Essa flexibilidade atrela a estrutura de TI de modo mais conciso aos problemas de negócio. Portanto, para gerentes e administradores, SOA representa em uma capacidade maior de adaptação às exigências, e como a companhia exibe seus serviços, interna e externamente.

Para os arquitetos de TI, SOA é como a companhia organiza seus recursos: fornecedores de serviços, consumidores e descrições de serviços. Isso simplifica os elementos que eles deverão tomar conta, devido ao baixo acoplamento dos componentes.

Para os desenvolvedores, SOA representa um conjunto de especificações, protocolos de interface e comunicação. Ao mesmo tempo que traz maior liberdade para a implementação de suas soluções.

Com SOA é possível centralizar mais facilmente a gestão dos recursos e fazer medições sem ter de inferir na implementação de cada aplicativo. SOA facilita igualmente o recolhimento de dados de indicadores de negócio (quantidade de utilização de determinados serviços, recursos humanos, gastos, etc) quanto indicadores técnicos (desempenho, precisão dos dados trafegados, workloads e outros). Uma vez identificados pontos a melhorar, recomeçar o ciclo para a implantação de melhorias será muito menos doloroso, já que não será mais necessário mexer no que já funciona devidamente.

SOA não possui um conceito rigidamente definido, mas como existem padrões bem definidos que a habilitam, a indústria de software é livre para criar ferramentas que auxiliem seu projeto, implantação e monitoramento. O mais interessante de tudo isso, em minha opinião, é que como não há disputa na indústria para o conceito de SOA, o que prevalece são o bom senso e a real procura por agregar o maior valor possível de software ao negócio. E por influenciar tantas áreas de uma organização, transcende as bordas de TI.

Referências

A practical application of SOA – IBM developerWorks

Tivemos a participação de 86 colegas respondendo o cargo, o cargo registrado em carteira, tempo te formado, salário bruto e a quantidade de funcionários na empresa. Apesar do relativamente pequeno número de respostas, essa pesquisa nos possibilita ter uma visão razoável de quão aquecido anda o mercado de engenharia de computação no Brasil.Pretendemos fazer essa pesquisa anualmente, incrementando e evoluindo as perguntas conforme os feedbacks recebidos. Continuarei meu árduo trabalho de incentivo, com amor e carinho, para que mais pessoas respondam ao questionário.

A tabela da pesquisa pode ser vista nesse arquivo do Google Spreadsheet, mas, a tabulação e geração dos dados foi feita nesse arquivo de Excel.

Como pode ser observado no formulário de preenchimento, foram definidos intervalos para os salários, portanto, os valores das médias não são exatos (uma pessoas que ganha R$11.000,00 aparecerá nos dados como se ganhasse R$25.000,00) e devem ter gerado certa discrepância. Lição aprendida… ano que vem, deixaremos que cada um coloque o salário exato para melhorar a precisão da pesquisa.

Salário médio

O salário médio dos 86 participantes é de R$6.854,65, um salário muito bom, quando se observa que a média da região metropolitana de São Paulo (a maior do país) é de menos de R$1.700,00, conforme apuração do IBGE.

Cargo

Como o campo de cargo podia ser preenchido livremente, obtivemos respostas bastante diversas (bombeiro?), dificultando um pouco a tabulação dos dados. Foram agrupados cargos que, ao meu ver, pareciam coerentes, mas, ainda assim, obtivemos um “outros” de 14% das respostas.

(clique nas imagens para ampliar)

De todos os cargos preenchidos, as maiores médias salariais foram a de analistas financeiros e de negócios e a de engenheiros de software. As menores médias ficaram com desenvolvedores e analistas de sistema.

Tempo formado

Tivemos uma boa divisão de participantes para cada um dos tempos definidos, nos possibilitando ter uma boa visão.

Seguindo para os resultados, obtivemos o padrão esperado por um engenheiro. Quem se formou há mais tempo, ganha mais, com uma média de R$12.100,00 (observando a minha cagada na hora de criar os valores – 10.000 a 25.000). Quem se formou a menos de um ano ganha uma média de aproximadamente R$4.500,00.

Quantidade de funcionários da empresa

Aqui as respostas foram bem discrepantes com uma maioria esmagadora de politécnicos trabalhando em empresas com mais de 100 funcionários.

Essa discrepância acaba invalidando um pouco a pesquisa, já que pontos fora da curva acabam contando muito quando temos apenas meia dúzia de pessoas em um determinado tamanho de empresa.

Conclusões

A conclusão geral dessa pesquisa é que precisamos fazer mais pesquisas! Os dados obtidos foram satisfatórios, mas, mais respostas, saltos salariais menores e outras perguntas teriam melhorado em muito seu valor.

Concluo que nossa área está quente, mas precisamos “valorizar nosso passe” ainda mais.

Até a próxima, com melhores e perguntas e, se meu “amor e carinho” der certo, mais respostas!