Aumentando a produtividade do desenvolvedor com a plataforma ArcGIS?

Somos uma pequena equipe de desenvolvedores .NET. Temos ampla experiência em GIS e nenhum de nós é novo no desenvolvimento de software / banco de dados ou administração de sistemas. Temos formação técnica e muitos anos de experiência no setor. Participamos de Esmits Developer Esri.

A tecnologia da Esri - principalmente ArcGIS Server, ArcSDE e ArcObjects - desempenha um papel pequeno, mas necessário, em todo o software que desenvolvemos. Apesar do status minoritário da ESRI em nossa pilha de tecnologias, gastamos uma quantidade excessiva de tempo solucionando problemas de erros indescritíveis, criando soluções alternativas, decifrando suas vagas mensagens de erro, rastreando problemas de desempenho e processos de reciclagem.

Normalmente, nossos problemas decorrem de bugs genuínos, tratamento inadequado de exceções, limitação de decisões de projeto / arquitetura, falta de documentação, instabilidade ou alguma combinação deles. (Estou falando da pilha ESRI aqui.)

Do ponto de vista de um gerente de projeto, estou muito preocupado com a produtividade da equipe. Isso nos custa muito tempo. Não temos tempo para aprender todas as idiossincrasias da pilha ESRI, mas ainda precisamos fazer as coisas. (Não posso viver com isso, não posso viver sem ele.)

Que sugestões pragmáticas você tem para aumentar a produtividade do desenvolvedor com a ESRI no mix?

Não estou procurando sugestões sobre pilhas de tecnologias alternativas.

Para o desempenho, parece que a melhor solução é escrever o código proxy C ++ no ArcObjects, conforme mencionado neste artigo . No exemplo ESRI, a remoção do uso pesado da interoperabilidade COM gera um aumento de desempenho de 6x.

A ESRI também fornece sugestões / práticas recomendadas para lidar com as mensagens de erro criptográficas COM - e uma explicação dos códigos de erro HRESULT .

Além desses, muitos dos problemas de configuração estão relacionados ao Windows e, portanto, um bom conhecimento de gerenciamento de servidores Windows, IIS, serviços Windows, logs de eventos do Windows, registro, objetos COM registrados etc.

Além desses artigos, há várias abordagens de desenvolvimento mais genéricas que você pode achar úteis.

Abordagens de desenvolvimento de software

• Use os serviços da Web, tanto quanto possível, para os dois dados geográficos (serviços WMS, WFS, ArcGIS REST). Essa separação facilita as coisas para depurar e manter.
• Sempre que possível, instale sistemas para limpar as instalações do Windows. Crie scripts de instalação para que você possa recriar todo o sistema do zero, sem precisar confiar na memória e nos processos manuais. Máquinas virtuais são perfeitas para isso.
• Tanto quanto possível, mantenha .NET e DLLs puros com código específico ESRI separados
• Você pode começar a tentar fazer mais "levantamento / processamento pesado" no banco de dados, por exemplo, diretamente no SQL Server 2008 com as novas classes Geometry e Geography

Comunicação

• Publique os erros indescritíveis no GIS SE / StackOverflow, e se você encontrar as soluções, também encontrei respostas anteriores que escrevi enquanto procurava pelo mesmo bug que tinha esquecido completamente seis meses depois.
• Faça anotações e, idealmente, permita que elas sejam pesquisadas por outras pessoas da equipe. Eu tentei wikis, mas a falta de colar imagens foi um obstáculo suficiente para me impedir de fazê-lo regularmente. Atualmente, uso o Microsoft OneNote, que é perfeito para rastrear erros, URLs, capturas de tela. Também pode ser compartilhado.
• Para abordagens técnicas mais detalhadas, poste-as em um blog. Parece haver muito menos compartilhamento de detalhes no mundo ESRI, possivelmente devido ao medo de que outras pessoas tirem vantagem comercial, no entanto, um blog decente é um bom anúncio para os serviços da sua empresa

Receio que não surjam muitas respostas boas dessa pergunta. Mas é uma boa ... o desempenho dos produtos ESRI é uma preocupação minha há algum tempo.

Meu comentário acima está consultando a necessidade de produtos ESRI ou você pode migrar para uma pilha de tecnologia diferente. Se você estiver desenvolvendo produtos da ESRI para integrar-se aos sistemas da ESRI para atrair os usuários da ESRI, estará preso a uma base de código da ESRI que foi portada ou distorcida para se adequar às plataformas modernas de desenvolvimento e usuário.

Alguém da ESRI, por favor, corrija-me se estiver errado. A maioria das bibliotecas .NET da ESRI são invólucros para objetos COM, dos quais existem custos indiretos para acessar e oferecer relatórios e manipulação de erros ambíguos na melhor das hipóteses. Compreender os objetos COM subjacentes e o envolvimento deles em sua base de código o ajudará a projetar melhor seu código para se adequar à operação deles. Esse fato me ajuda a aumentar o desempenho em meus scripts Python 10 vezes. O que uma vez levou 40 minutos agora leva 4 e com um pouco de ajustes agora é reduzido para 2,5 minutos!

Ouvi coisas boas com o ArcGIS 10, mas não prenda a respiração.

Se você estiver usando produtos ESRI para fornecer uma solução GIS em seu software, prenda-se a um dos muitos projetos de código aberto oferecidos e construa a partir daí. O @capdragon oferece um desses conjuntos de aplicativos que fornecerão uma grande flexibilidade e escalabilidade com uma equipe de suporte de desenvolvedores que pensam na nuvem para ajudá-lo.

O desenvolvimento com produtos da ESRI é um jogo de campo mental com ambiguidade, hacks obscuros e inconsistência, os principais players se você estiver tentando fazer algo inovador e fora do Procedimento Operacional Padrão da ESRI.

Quero que alguém me prove que está errado!

Na minha experiência de trabalho com a ESRI, quanto mais você se afastar do ArcObjects, maior a probabilidade de obter sucesso. Em termos práticos, isso significa que se você pode usar as APIs REST mais recentes para fazer o que está fazendo, sempre deve acessar o ArcGIS dessa maneira.

Eles parecem ter aprendido algo com a falha total que foi o ADF da Web em Java / .net, e as APIs REST são muito simplificadas e têm um histórico comparativamente ótimo em apenas trabalhar sem muito barulho. A maneira mais simples de acessar a API REST é se você estiver trabalhando em Javascript / Flex / Silverlight, pois o ESRI fornece bibliotecas para aqueles que são muito bons, mas é apenas uma interface REST padrão e você pode conversar com quase tudo.

Há coisas que você não pode fazer dessa maneira, mas não posso enfatizar o suficiente como é melhor trabalhar com quase qualquer outra coisa na pilha ESRI. Quando você tem que trabalhar com o ArcObjects (ou com o ArcObjects envolto em .net), tudo o que você pode fazer é criar uma documentação extremamente boa no seu código e rezar para que eles não quebrem as coisas no próximo patch (o que provavelmente acontecerão, conhecendo-os )

Mantenha sua manutenção de suporte atualizada. A única coisa mais frustrante do que tentar descobrir um problema de código é tentar resolvê-lo sem a ajuda das pessoas que escreveram o código. E você não receberá nenhuma ajuda da ESRI se não tiver um contrato de manutenção com eles. (Você pode obter ajuda neste site ou nos fóruns da ESRI, mas isso está muito longe de falar diretamente com eles.)

Fique por dentro dos service packs e patches. Não há garantia de que você não terá problemas, mas pode responder com segurança "Sim" quando solicitado pelo suporte se tiver a versão / atualizações mais recentes instaladas.

Contribua com suas soluções alternativas para a comunidade (blogs, perguntas aqui, etc.). Se um número suficiente de pessoas fizesse isso, imagino que duas coisas aconteceriam: uma, mais desenvolvedores estariam cientes dos problemas e teriam uma chance de eliminá-los mais rapidamente e dois, os problemas seriam corrigidos mais rapidamente pela ESRI (nada como uma ampliação vidro para mover as formigas, existe?).

Também sou desenvolvedor de ESRI que luta constantemente com esse produto diariamente. Como não tenho suporte de manutenção, não recebo muitos comentários dos desenvolvedores.

É realmente muito frustrante quando algo "Simplesmente não funciona" (ao contrário de IJW - Simplesmente funciona), não importa o quanto você tente.

O que eu tento vencer a luta:

• Faça perguntas (muito)
• Leia a referência do ArcObjects SDK (muitas - repetidamente)
• Experimente diferentes configurações

O caminho mais curto para obter um resultado é perguntar a alguém que já teve o mesmo problema; portanto, se alguém entrar nesse problema e encontrar uma solução, provavelmente o informará.

A documentação é boa, mas carece de descrições de elementos-chave e detalhes importantes - portanto, volte para 1.

Experimentação também funciona. Crie um programa de console e teste fora. As estruturas de teste de unidade podem ajudá-lo a fazer tudo dentro de um IDE, mas testar cenários diferentes.

A biblioteca de ESRI mais complicada ou estranha é o banco de dados geográficos e pode fornecer resultados bizarros, dependendo das condições, portanto, tente dominá-lo.

Tente usar PostGIS> GeoServer> OpenLayers. Veja como isso funciona para sua equipe.