Avançar para a área de conteúdo

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

A primeira vez que acessar o developerWorks, um perfil será criado para você. Informações do seu perfil (tais como: nome, país / região, e empresa) estarão disponíveis ao público, que poderá acompanhar qualquer conteúdo que você publicar. Seu perfil no developerWorks pode ser atualizado a qualquer momento.

Todas as informações enviadas são seguras.

  • Fechar [x]

Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

Todas as informações enviadas são seguras.

  • Fechar [x]

Técnicas para o Desenvolvimento Rápido de Soluções Remotas

Uma abordagem de cumprimento progressivo para equipes pequenas de design e desenvolvimento

Tom Cook, Senior Technical Staff Member, IBM
Thomas Cook é Senior Technical Staff Member da IBM, responsável por liderar equipes de designers e desenvolvedores na criação de soluções móveis inovadoras. Seu trabalho na IBM envolveu soluções remotas, sistemas embarcados, sistemas de jogos, mundos virtuais e sistemas operacionais.
Charisse Lu, Software Engineer, IBM
http://www.ibm.com/developerworks/i/p-charisse_lu.jpg
Charisse Lu trabalha com tecnologias da web e espaços virtuais 3D e — mais recentemente — atua como líder técnico da equipe na área de inovações remotas no laboratório do CIO IBM, criando soluções remotas para funcionários da IBM.
John Reddin, Software Engineer, IBM
John Reddin é engenheiro de software e trabalha na IBM desde o terceiro trimestre de 2009. Passou a fazer parte da IBM como estagiário do Extreme Blue. Em seguida, trabalhou no IBM Connections e atualmente trabalha com escritório do CIO em inovações remotas. John cursou Ciência da Computação na Faculdade Trinity de Dublin. Seus principais interesses são arquiteturas de software escalável, desenvolvimento remoto e música computacional, uma área na qual ele tem títulos publicados.
Emil Varga, Software Engineer, IBM
Emil Varga atua como engenheiro de software na IBM Dublin desde 2008. Trabalhou na equipe de wikis do Lotus Connections para o Lotus Connections 2.5 e 3.0 antes de passar a fazer parte do Laboratório de Inovações Remotas do CIO no início de 2012. Tem bacharelado e mestrado em Ciência da Computação e Engenharia pela Universidade de Belgrado, na Sérvia. Gosta de aprendizado de máquina, Linux, desenvolvimento da web e linguagens de programação funcionais.

Resumo:  As necessidades de acesso a dados e compartilhamento dos usuários remotos corporativos não estão sendo atendidas pelos sistemas de arquivos e de gerenciamento de conteúdo convencionais. Felizmente a implementação rápida de uma solução de acesso ao conteúdo multidispositivo é algo acessível — inclusive para as equipes pequenas e internas de design e desenvolvimento — por meio de um processo de desenvolvimento eficiente que aproveita tecnologias já existentes. Veja como a equipe de inovação remota do Laboratório IBM CIO realizou rapidamente o piloto de uma solução interna que aumenta a produtividade dos usuários oferecendo-lhes um compartilhamento de arquivos fácil e flexível em todas as plataformas aprovadas.

Data:  06/Ago/2012
Nível:  Intermediário Também disponível em :   Inglês
Atividade:  1062 visualizações
Comentários:  


A equipe de inovação remota do Laboratório IBM CIO da IBM desenvolve soluções internas para ajudar os funcionários da IBM a serem mais produtivos e terem mais segurança usando os dispositivos móveis. No final de 2010, os funcionários estavam com dificuldade de compartilhar arquivos nos laptops, telefones celulares e tablets. O acesso aos sistemas clássicos de gerenciamento de conteúdo ou de arquivos compartilhados a partir de dispositivos móveis era limitado e trabalhoso. Sem um complemento completo de plug-ins, certos arquivos não seriam renderizados ou não funcionariam ao serem transferidos. Além disso, os arquivos não podiam ser portados facilmente entre dispositivos de desktop e dispositivos móveis.

A nossa equipe precisava oferecer aos funcionários uma solução móvel para acessar o conteúdo interno da IBM por meio de dispositivos aprovados. Decidimos desenvolver uma solução piloto para atuar como uma janela para os dados completos e fornecer um pequeno cache de dados transportáveis. Os dados transportáveis seriam transformados em formatos compatíveis para ajudar os usuários a consumir melhor o conteúdo em várias plataformas. Demos ao projeto o nome MyMobileHub. Com uma equipe pequena, em poucos meses, precisávamos mostrar uma prova de conceito com habilitação em plataformas Android, BlackBerry e iOS. Poucos meses depois disso, precisaríamos ter um piloto nativo funcional.

Muitos dos conceitos de desenvolvimento rápido usados no piloto e abordados neste artigo são bem conhecidos na área de desenvolvimento remoto. Veja como utilizamos esses conceitos para desenvolver uma solução interna multidispositivo de ponta a ponta para ter uma ideia de como fazer isso com a mesma velocidade no seu próximo piloto ou projeto remoto.

Planejando um piloto de desenvolvimento rápido

Geralmente, os pilotos de inovação são um processo iterativo: desenvolva rapidamente uma solução utilizável e compartilhe-a com um conjunto de colegas próximos e adotantes precoces. Em seguida, expanda a funcionalidade juntamente com a base de usuários, usando os comentários e sugestões como auxílios para a navegação. Trata-se de um protocolo comum para explorar uma nova solução.

Para fazer um piloto bem-sucedido na arena móvel, em rápida evolução, precisávamos de uma abordagem totalmente diferente ao desenvolvimento. Exploramos várias tecnologias reutilizáveis que poderiam nos ajudar. Escolhemos uma combinação de tecnologias de software livre e ferramentas internas da IBM que preenchem os critérios de desenvolvimento rápido, suporte para várias plataformas e recursos de ponta.

No lado do servidor, escolhemos a estrutura Play, uma estrutura Java RESTful e stateless baseada nos conceitos de model view controller (MVC) do Ruby on Rails. Para o desenvolvimento no lado do cliente, escolhemos PhoneGap, Dojo e Dojo Mobile para ter uma aparência e experiência do usuário consistente em todos os clientes. (Consulte Recursos abaixo para ver os links.)

Já que o cache pequeno dos arquivos que planejávamos transformar teria que ser agrupado, decidimos usar um banco de dados simples em vez de um sistema de arquivos. Selecionamos o Apache CouchDB, um banco de dados no SQL sem esquema e orientado a documentos que suporta o armazenamento de documentos com visualizações simples e rápidas baseadas no MapReduce.

O CouchDB e o Play funcionam bem juntos e permitiram que trabalhássemos rapidamente. Usamos o Apache ActiveMQ para gerenciar as várias mensagens e tarefas que compreendem o pipeline de conversão de documentos. Finalmente, um frontend do Servidor HTTP Apache nos forneceu alguns controles adicionais e balanceamento de carga. Novamente, neste piloto, estávamos explorando a viabilidade da solução e entendendo os requisitos dos usuários e os padrões de uso. Os principais componentes, conceitos e designs que eventualmente podem ser reutilizados são movidos facilmente para outras plataformas quando estão prontos para a produção.

Para nos mantermos atualizados com o conjunto de dispositivos móveis em constante expansão, usamos uma ferramenta interna para nos ajudar a identificar as especificações de dispositivos móveis a partir do projeto WURFL (consulte Recursos para ver o link), um repositório no qual informações como a funcionalidade do smartphone e o tamanho da estão prontamente disponíveis. A ferramenta nos ajudou a determinar facilmente a melhor forma de exibir o conteúdo do aplicativo de uma forma compatível com os recursos do dispositivo.

O valor que obtivemos com o nosso piloto foi, além do produto interno geral (código) propriamente dito, um entendimento em relação ao uso do piloto. E o mais importante: ganhamos a experiência de resolver problemas para o usuário remoto e conhecedor de tecnologia. Nossos adotantes precoces falavam claramente se os problemas foram resolvidos ou não, se o produto combinava com o fluxo de trabalho e se atendia as expectativas de facilidade de uso e produtividade. Caso não estivéssemos cumprindo a missão de deixar os usuários mais produtivos e seguros, nós reinventávamos a solução para abordar o problema de um ângulo novo.


O MyMobileHub em poucas palavras

A nossa solução fornece uma forma fácil para os usuários compartilharem arquivos entre si. Em vez de enviar arquivos por email para serem abertos nos dispositivos móveis, eles podem arrastar e soltar arquivos do desktop para o navegador com o MyMobileHub. Fazemos upload do arquivo para o nosso servidor por meio do navegador. Um usuário pode se conectar ao mesmo servidor a partir de um dispositivo móvel — mas nós oferecemos uma UI diferente, na qual é possível ver o arquivo independentemente do formato original. Também aproveitamos os recursos remotos de câmera e voz para permitir que os usuários criassem e fizessem upload de conteúdo multimídia com facilidade.

Visualização no laptop e desktop

Na área de laptop e desktop, só suportamos navegadores com o recurso de arrastar e soltar. Os usuários arrastam marcadores, documentos ou outros arquivos na janela do navegador, como mostra a Figura 1. No caso dos documentos cujo formato entendemos, fornecemos visualizações e criamos versões em PDF que podem ser consumidas facilmente em dispositivos móveis. Pretendemos converter outros tipos de arquivo, por exemplo, converter arquivos de áudio para arquivos de texto.


Figura 1. Recursos do MyMobileHub

Os navegadores de desktop fornecem uma forma conveniente de fazer upload e organizar arquivos. Uma imagem de visualização é gerada automaticamente para cada arquivo. Os usuários podem selecionar uma visualização de lista ou em grade para gerenciar os arquivos visualmente. Os rótulos dinâmicos com código de cor ajudam a organizar os arquivos sem a inconveniência de uma hierarquia clássica de sistema de arquivos. Os filtros de arquivo e rótulo, juntamente com um recurso de pesquisa instantânea, facilitam e agilizam a localização de arquivos.

Aplicativos da web móveis

Os navegadores em smartphones e tablets são muito avançados. Usando Dojo Mobile e JavaScript, pode-se entregar um aplicativo rico por meio do navegador. Os serviços de identificação de dispositivos internos verificam o tipo de dispositivo e nos ajudam a selecionar a combinação reutilizável correta de código, HTML e CSS para fazer o download para o dispositivo. Dependendo dos recursos do dispositivo, entregamos a página que é melhor para o monitor. Em um dispositivo como o iPad, a página do aplicativo da web é muito semelhante à página do aplicativo da web do navegador do desktop, fornecendo uma experiência do usuário sem problemas. Como é possível ver na Figura 2, a experiência do usuário é mais semelhante à de um aplicativo que à de uma página da web. Os usuários podem solicitar que o arquivo seja transferido por download, solicitar que a versão em PDF seja transferida por download para visualização e inserção na estante ou ativar um marcador para uma página da web.


Figura 2. Aplicativo da web móvel MyMobileHub

Aplicativos remotos nativos

Os aplicativos nativos do MyMobileHub são semelhantes aos aplicativos da web que executam no navegador remoto, mas têm o recurso adicional de fazer upload do conteúdo gerado a partir do dispositivo em si. Os usuários podem gravar áudio ou vídeo, tirar uma foto ou selecionar uma foto da galeria. Tudo isso pode ser transferido por upload diretamente a partir do MyMobileHub.


Figura 3. Aplicativo nativo do MyMobileHub


Onde a eficiência começa: metodologia, abordagem e design

Antes de fazer o trabalho de codificação, pesquisamos várias tecnologias. A seleção da ferramenta foi um processo cuidadoso que nos colocou no caminho correto. Unimos os designers da experiência do usuário e da interface com o usuário. Unimos os desenvolvedores (os dois). Envolvemos o nosso especialista em desenvolvimento para a web (que mora no Brasil). Cada grupo foi responsável por orientar os demais em relação à eficiência dos vários conjuntos de ferramentas, como design de gráficos, HTML5, CSS, widgets de UI e recursos de servidor. Ao orientar uns aos outros, compartilhamos as dificuldades e técnicas de eficiência.

Também tomamos algumas decisões de comando, de não suportar certos níveis de sistema operacional e de navegador. Ao focar na entrega de navegadores habilitados para HTML5, pudemos simplificar o processo de desenvolvimento. Valeu a pena reconhecer as tendências tecnológicas relevantes e prever seu crescimento no software e no hardware. Por exemplo, cerca de três meses depois da nossa decisão de focar nos navegadores habilitados para HTM5, todos os dispositivos móveis suportavam HTML5.

Dados únicos/CSS múltiplo

Uma de nossas primeiras grandes decisões de design, do ponto de vista remoto, foi realizar o push do máximo possível de itens da UI e de formatação em CSS e HTML5. Dessa forma, simplificamos o código e o unificamos em todas as plataformas remotas.

Precisávamos suportar iPhone, iPod Touch, iPad, BlackBerry, telefones Android, e tablets Android de tamanho médio e completo, bem como desktops Mac, Linux e Windows. Cada linha de código customizado em cada plataforma aumenta a exposição da confiabilidade e a complexidade. Nosso modelo dados únicos/CSS múltiplo permitiu o uso da mesma origem de dados JavaScript Object Notation (JSON) para criar UIs totalmente diferentes para essas plataformas apenas com um subconjunto de CSS customizado para cada uma.

Para conseguir isso, escrevemos módulos customizados de CSS para cada uma de nossas plataformas. No caso dos nossos aplicativos da web, quando um dispositivo solicita HTML a partir do nosso servidor, detectamos o tipo de dispositivo e carregamos dinamicamente o módulo CSS customizado. Em aplicativos nativos, já sabemos qual tipo de plataforma pode carregar o aplicativo — portanto, podemos limitar as customizações ainda mais, a coisas como o tamanho da tela e a versão do OS. Os aplicativos iPhone e iPad — que compartilham cerca de 99,9% do código — são exemplos disso mas, — graças ao poder do CSS dinâmico — têm a aparência correta para o tamanho da tela.

A Listagem 1 mostra o módulo CSS do iPhone e iPad:


Listagem 1. Módulo CSS para o iPhone e iPad

.loginScreen {
    background-image: url(../images/splashBG.png);
    background-repeat: no-repeat;
    background-size: 320px;
}

.loginScreeniPad {
    background-image: url(../images/splashBGiPad.png);
    background-repeat: no-repeat;
    background-size: 768px;
}

Incluindo um nível de eficiência com o PhoneGap

Nossa equipe ampliada incluía desenvolvedores especialistas no desenvolvimento de aplicativos customizados para a maioria das plataformas remotas. Normalmente, pediríamos para cada especialista em plataforma remota participar e desenvolver um aplicativo customizado. Entretanto, por causa do prazo curto e da UI relativamente simples que idealizamos, adotamos uma abordagem diferente. Trabalhando diligentemente para realizar o push do máximo possível da função dos aplicativos da web em HTML5 e CSS, pudemos o PhoneGap para encapar o HTML5 e o CSS em aplicativos nativos.

O conceito de ferramentas como o PhoneGap é simples. Você começa com um aplicativo da web móvel escrito usando tecnologias JavaScript, HTML e CSS. Em seguida, o PhoneGap o empacota como um aplicativo nativo cuja principal tarefa é ativar um navegador interno para visualizar somente o aplicativo da web (uma visualização na web). As APIs nativas — como a da câmera do dispositivo — agora podem ser acessadas por meio de chamadas de JavaScript que vinculam o aplicativo da web ao código nativo. O código Javascript para acessar a câmera é igual em todos os dispositivos, reforçando mais uma vez o objetivo de uma base de código única para várias plataformas. O fragmento de código da Listagem 2 mostra como capturar uma imagem em um dispositivo usando somente uma função Javascript simples:


Listagem 2. Capturando uma imagem usando uma função Javascript simples

mmh.phonegapActions.captureImage = function() {
    navigator.device.capture.captureImage(
		dojo.partial(mmh.phonegapActions._captureSuccess, "image"), 
            mmh.phonegapActions._captureError, {limit: 1});
};

O uso de uma ferramenta como o PhoneGap tem certas desvantagens. Certamente, não é tão eficiente e rápido quanto um aplicativo escrito em código nativo. Mesmo assim, algumas tarefas de execução pesada, como animações com gráficos complexos, exigiriam execuções nativas para serem responsivos. As ferramentas de depuração e teste ainda estão em sua infância, mas essa situação está melhorando com o surgimento de ferramentas como o Ripple e o WEINRE (consulte Recursos). Você não tem o mesmo controle sobre as camadas de hardware que teria com um aplicativo nativo de fábrica. (Pode-se superar essa desvantagem escrevendo plug-ins customizados de PhoneGap. Muitos plug-ins estão sendo disponibilizados para tarefas específicas.) No entanto, em nosso caso, os benefícios da reutilização significativa compensam as desvantagens do PhoneGap.

O fato de que o design do aplicativo deve ser centrado no nativo é outro motivo para usar o PhoneGap. O conhecimento de diversas plataformas remotas ajuda os desenvolvedores de aplicativos a obter a aparência nativa sem escrever código nativo. No nosso ciclo de inovação atual, a velocidade com a qual podemos pegar aplicativos da web bem projetados e movê-los para aplicativos nativos está funcionando bem. Usando o PhoneGap, transformamos o aplicativo da web Android em aplicativo nativo com suporte para gravação de áudio/vídeo/imagem, a janela de notificação nativa e os botões de menu de hardware/voltar/início em menos de dois dias. Também pudemos usar esse código para o BlackBerry.

Realizando a cascata de mudanças de forma eficiente

Às vezes, mesmo se você fez um ótimo trabalho em conjunto com os designers da experiência do usuário e da UI para criar uma UI que, na sua opinião, é a melhor possível, os usuários reclamam, dizendo que não sabem realizar uma tarefa simples. (Como eu não vi isso?)

Então, é feita uma mudança que simplifica a experiência do usuário e agora é necessário efetuar essa mudança em cascata para todos os aplicativos da web e aplicativos nativos. Sem um alto nível de reutilização nas plataformas, os seus desenvolvedores devem trabalhar em cada plataforma específica e fazer a mudança várias vezes. Multiplicando isso pelo número de casos de teste que devem ser executados novamente, as mudanças que eram pequenas se tornam monstruosas. Novamente, adotando a formatação HTML5 e CSS, é possível fazer a maioria das mudanças em um nível mais baixo. As mudanças na codificação com a diretriz dados únicos/CSS múltiplo se tornam menos problemáticas. Após o teste dos aplicativos da web, é possível rolar as alterações para as soluções de aplicativo nativo do PhoneGap, concluindo o processo.

Um exemplo que encontramos é a inclusão de um botão de atualizar para dar aos usuários a confiança de que eles podem voltar a fazer a varredura dos dados que podem estar fora de sincronização. Desenvolvemos e testamos esse recurso no Android e, em seguida, reutilizamos o código em todas as plataformas com um alto grau de confiança. Pequenos ajustes no CSS ajudaram a obter a aparência correta em todos os dispositivos, finalizando o recurso.

Adotando esse método de reutilização, estimamos que seja necessário usar 10% do tempo de desenvolvimento para fazer um novo recurso funcionar em todas as plataformas após os 90% iniciais empregados no desenvolvimento. Entretanto, isso não se aplicaria caso o mesmo recurso tivesse que ser reescrito usando APIs, linguagens e estruturas diferentes para cada plataforma nativa.

Esse método de reutilização também se aplica a correções de erros. Se um erro é detectado na UI do aplicativo da web para iPhone, é provável que o erro se repita nos aplicativos para iPad, Android e BlackBerry, porque eles compartilham 99% do código. Ao corrigir o erro em uma plataforma, corrigimos todos os aplicativos da web. Além disso, fica fácil identificar a origem dos erros nas versões nativas.

Também temos um conjunto de sprites para todos os gráficos — mas, com alguns CSS e o Dojo Mobile, temos a aparência correta para o dispositivo sem muito trabalho adicional.

Não é um processo perfeito

Continuamos desenvolvendo e aperfeiçoando o nosso processo para precisar de menos customização com um suporte melhor em todas as plataformas. A navegação nativa em vários dispositivos é um exemplo disso. Os dispositivo de iOS não incluem botões de voltar ou de menu no hardware, ao passo que os dispositivos BlackBerry e Android (pelo menos até o Android 4.0) incluem. Além disso, o funcionamento dos botões de menu do Android e do BlackBerry é diferente. Para superar essa disparidade, separamos o nosso código Javascript em widgets que podem ser inseridos ou modificados para se ajustar a cada plataforma com pouca ou nenhuma interferência no restante do código. É importante não só separar o código do CSS, mas também modularizar os componentes para que o código possa ser reutilizado ou substituído com facilidade.

Conseguimos minimizar a quantidade de codificação de casos especiais seguindo a nossa política de dados únicos/CSS múltiplo.

Aplicativos da web vs. aplicativos nativos

É melhor implementar aplicativos da web ou aplicativos nativos? De acordo com a nossa experiência na área de inovação móvel do laboratório CIO, a nossa resposta é: as duas coisas. Graças às melhorias recentes nos navegadores dos smartphones e tablets, os aplicativos da web em dispositivos móveis funcionam bem. Atualmente, os aplicativos nativos oferecem mais acesso aos recursos nativos de hardware.

Entretanto, essa decisão envolve mais do que avaliar qual é o melhor. Detectamos que os usuários que estão fazendo o test drive das nossas soluções estão hesitando em instalar um aplicativo nativo. Alguns simplesmente não estão dispostos a se comprometer com a nossa solução. Desejam fazer um test drive antes de instalar um aplicativo nativo. E os aplicativos nativos requerem, de fato, um pouco de manutenção e atualizações.

Ao suportar aplicativos da web e aplicativos nativos, podemos manter uma política de instalação zero para a nossa inovação. Além disso, os usuários ciclam por mais dispositivos do que se pensa. Ao obterem um novo dispositivo, eles fazem um test drive do nosso aplicativo da web antes de instalar o aplicativo nativo. Sempre há compensações entre função, design e tempo de implementação.


Conclusão

A realização do piloto de uma solução usando o modelo descrito ajuda equipes como a nossa a explorar o valor principal de suas ideias. O processo inicia com uma pesquisa minuciosa sobre as melhores ferramentas — tanto as de software livre quanto as internas — disponíveis para resolver o problema. Em seguida, é possível analisar as vantagens e desvantagens da função e do design. Às vezes, o entendimento do valor da rapidez de entrada no mercado, comparado ao da completude de funções, pode ser o fator necessário para ter um piloto bem-sucedido. Depois que o valor principal é articulado por meio do feedback e adoção pelos usuários, o processo de transformar o piloto em um serviço ou produto de produção pode ser iniciado.

Esperamos que este artigo tenha mostrado algumas técnicas para o seu próximo projeto que ajudarão a sua equipe — e, em última análise, os usuários da sua solução — a serem mais eficientes e produtivos. Nosso piloto envolve muitas mudanças nos requisitos dos usuários, mas acreditamos que a nossa pequena equipe pode dar conta das solicitações de mudança dos usuários. Otimizamos o design e desenvolvemos um processo que cicla em períodos de algumas semanas, graças à eficiência da metodologia selecionada no início.


Recursos

Aprender

Obter produtos e tecnologias

  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas no no Ambiente de Simulação da SOA aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.

Discutir

  • Participe da Comunidade do developerWorkse conecte-se a outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Sobre os autores

Thomas Cook é Senior Technical Staff Member da IBM, responsável por liderar equipes de designers e desenvolvedores na criação de soluções móveis inovadoras. Seu trabalho na IBM envolveu soluções remotas, sistemas embarcados, sistemas de jogos, mundos virtuais e sistemas operacionais.

http://www.ibm.com/developerworks/i/p-charisse_lu.jpg

Charisse Lu trabalha com tecnologias da web e espaços virtuais 3D e — mais recentemente — atua como líder técnico da equipe na área de inovações remotas no laboratório do CIO IBM, criando soluções remotas para funcionários da IBM.

John Reddin é engenheiro de software e trabalha na IBM desde o terceiro trimestre de 2009. Passou a fazer parte da IBM como estagiário do Extreme Blue. Em seguida, trabalhou no IBM Connections e atualmente trabalha com escritório do CIO em inovações remotas. John cursou Ciência da Computação na Faculdade Trinity de Dublin. Seus principais interesses são arquiteturas de software escalável, desenvolvimento remoto e música computacional, uma área na qual ele tem títulos publicados.

Emil Varga atua como engenheiro de software na IBM Dublin desde 2008. Trabalhou na equipe de wikis do Lotus Connections para o Lotus Connections 2.5 e 3.0 antes de passar a fazer parte do Laboratório de Inovações Remotas do CIO no início de 2012. Tem bacharelado e mestrado em Ciência da Computação e Engenharia pela Universidade de Belgrado, na Sérvia. Gosta de aprendizado de máquina, Linux, desenvolvimento da web e linguagens de programação funcionais.

Ajuda para Relatar Abuso

Relatar abuso

Obrigado. Esta entrada foi sinalizada para atenção do moderador.


Ajuda para Relatar Abuso

Relatar abuso

Falha no envio do Relatório de abuso. Tente novamente mais tarde.


developerWorks: Registre-se


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.

 


Na primeira vez que você efetua sign in no developerWorks, um perfil é criado para você. Informações selecionadas do seu perfil developerWorks são exibidas ao público, mas você pode editá-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocultá-los), e seu nome de exibição acompanharão o conteúdo que postar.

Selecione seu nome de exibição

Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

(Deve possuir de 3 a 31 caracteres.)


Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.

 


Classificar este artigo

Comentários

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Desenvolvimento móvel
ArticleID=828895
ArticleTitle=Técnicas para o Desenvolvimento Rápido de Soluções Remotas
publish-date=08062012