Augmenter la productivité des développeurs avec la plateforme ArcGIS?

Nous sommes une petite équipe de développeurs .NET. Nous avons une vaste expérience en SIG, et aucun d'entre nous n'est nouveau dans le développement de logiciels / bases de données ou l'administration de systèmes. Nous avons des diplômes techniques et de nombreuses années d'expérience dans l'industrie. Nous avons assisté aux sommets des développeurs d'Esri.

La technologie d'Esri - principalement ArcGIS Server, ArcSDE et ArcObjects - joue un petit mais nécessaire rôle dans tous les logiciels que nous développons. Malgré le statut minoritaire d'ESRI dans notre pile technologique, nous passons un temps excessif à résoudre les bugs insaisissables, à élaborer des solutions de contournement, à déchiffrer ses vagues messages d'erreur, à rechercher les problèmes de performances et à recycler les processus.

En règle générale, nos problèmes proviennent de bogues authentiques, d'une mauvaise gestion des exceptions, de la limitation des décisions de conception / d'architecture, du manque de documentation, de l'instabilité ou d'une combinaison de ces éléments. (Je parle de la pile ESRI ici.)

Du point de vue d'un chef de projet, je suis très préoccupé par la productivité de l'équipe. Cela nous coûte beaucoup de temps. Nous n'avons pas le temps d'apprendre chaque idiosyncrasie de la pile ESRI, mais nous devons encore faire avancer les choses. (Je ne peux pas vivre avec, je ne peux pas vivre sans.)

Quelles suggestions pragmatiques avez-vous pour augmenter la productivité des développeurs avec ESRI dans le mix?

Je ne cherche pas de suggestions sur les piles de technologies alternatives.

Pour les performances, il semble que la meilleure solution consiste à écrire du code proxy C ++ dans ArcObjects, comme mentionné dans cet article . Dans l'exemple ESRI, la suppression de l'utilisation intensive de l'interopérabilité COM donne une augmentation des performances de 6x.

ESRI donne également des suggestions / meilleures pratiques sur la gestion des messages d'erreur COM cryptiques - et une explication des codes d'erreur HRESULT .

Au-delà de ces problèmes, la plupart des problèmes de configuration sont liés à Windows, et donc une bonne connaissance de la gestion des serveurs Windows, IIS, des services Windows, des journaux d'événements Windows, du registre, des objets COM enregistrés, etc.

En plus de ces articles, il existe un certain nombre d'approches de développement plus génériques qui peuvent vous être utiles.

Approches de développement de logiciels

• Utilisez autant que possible les services Web pour les deux données géographiques (services WMS, WFS, ArcGIS REST). Cette séparation facilite les choses à déboguer et à maintenir.
• Dans la mesure du possible, installez des systèmes pour nettoyer les installations Windows. Créez des scripts d'installation afin de pouvoir recréer l'intégralité du système à partir de zéro sans avoir à vous fier à la mémoire et aux processus manuels. Les machines virtuelles sont parfaites pour cela.
• Dans la mesure du possible, séparez les fichiers .NET et DLL purs avec du code spécifique ESRI
• Vous pourriez commencer à essayer de faire plus de "levage de charges lourdes / traitement" dans la base de données, par exemple directement dans SQL Server 2008 avec les nouvelles classes Geometry et Geography

la communication

• Publiez les bugs insaisissables sur GIS SE / StackOverflow, et si vous trouvez les solutions aussi, j'ai trouvé les réponses précédentes que j'ai écrites moi-même en recherchant le même bug que j'avais complètement oublié environ 6 mois plus tard ..
• Prenez des notes et, idéalement, permettez-leur d'être consultables par les autres membres de l'équipe. J'ai essayé des wikis mais le manque d'images collées était un obstacle suffisant pour m'empêcher de le faire régulièrement. J'utilise actuellement Microsoft OneNote qui est parfait pour garder une trace des erreurs, des URL, des captures d'écran. Il peut également être partagé.
• Pour des approches techniques plus détaillées, publiez-les sur un blog. Il semble y avoir beaucoup moins de partage de détails dans le monde ESRI, peut-être par crainte que d'autres profitent commercialement, mais un blog décent est une bonne publicité pour les services de votre entreprise

Je crains que pas beaucoup de bonnes réponses ne viennent de cette question. Mais c'est une bonne chose ... la performance des produits ESRI me préoccupe depuis un certain temps.

Mon commentaire ci-dessus interroge le besoin de produits ESRI ou pouvez-vous migrer vers une autre pile technologique. Si vous développez avec des produits ESRI pour les intégrer aux systèmes ESRI afin d'attirer les utilisateurs d'ESRI, alors vous êtes coincé avec une base de code ESRI qui a été portée ou contorsionnée pour s'adapter aux plates-formes de développement et d'utilisateurs modernes.

Quelqu'un d'ESRI, veuillez me corriger si je me trompe La plupart des bibliothèques .NET d'ESRI sont des wrappers pour les objets COM, dont il existe des frais généraux pour accéder et offrir au mieux des rapports d'erreurs et une gestion ambigus. Comprendre les objets COM sous-jacents et leur implication dans votre base de code vous aidera à mieux concevoir votre code en fonction de leur fonctionnement. Ce fait m'aide à augmenter les performances de mes scripts Python 10 fois. Ce qui prenait autrefois 40 minutes en prend maintenant 4 et avec un peu de peaufinage est maintenant réduit à 2,5 minutes!

J'ai entendu de bonnes choses avec ArcGIS 10, mais ne retenez pas votre souffle.

Si vous utilisez des produits ESRI pour fournir une solution SIG dans votre logiciel, alors accrochez-vous à l'un des nombreux projets open source proposés et construisez à partir de là. @capdragon propose un tel ensemble d'applications qui vous fournira une grande quantité de flexibilité et d'évolutivité avec une équipe d'assistance de développeurs partageant les mêmes idées dans le cloud pour vous aider.

Le développement avec les produits ESRI est un jeu de champ d'esprit avec ambiguïté, hacks obscurs et incohérence des principaux acteurs si vous essayez de faire quelque chose d'innovant et en dehors de la procédure d'exploitation standard d'ESRI.

Je veux que quelqu'un me prouve le contraire!

D'après mon expérience de travail avec ESRI, plus vous vous éloignez d'ArcObjects, plus vous avez de chances de réussir. Concrètement, cela signifie que si vous pouvez utiliser les nouvelles API REST pour faire ce que vous faites, vous devez toujours accéder à ArcGIS de cette façon.

Ils semblent avoir appris quelque chose de l'échec total du Web ADF en Java / .net, et les API REST sont beaucoup plus simplifiées et ont un bilan relativement important pour travailler simplement sans trop de tracas. Le moyen le plus simple d'accéder à l'API REST est si vous travaillez en Javascript / Flex / Silverlight car ESRI fournit des bibliothèques pour celles qui sont assez bonnes, mais c'est juste une interface REST standard et vous pouvez lui parler avec presque n'importe quoi.

Il y a des choses que vous ne pouvez pas faire de cette façon, mais je ne saurais trop insister sur le fait qu'il est plus agréable de travailler avec presque tout le reste dans la pile ESRI. Lorsque vous devez travailler avec ArcObjects (ou les ArcObjects encapsulés .net), tout ce que vous pouvez vraiment faire est de créer une documentation extrêmement bonne dans votre code et de prier pour qu'ils ne cassent pas les choses dans le prochain patch (ce qu'ils feront probablement, en les connaissant). ).

Gardez votre maintenance de support à jour. La seule chose plus frustrante que d'essayer de comprendre un problème de code est d'essayer de le résoudre sans l'aide des personnes qui ont écrit le code. Et vous ne recevrez aucune aide d'ESRI si vous n'avez pas d'accord de maintenance avec eux. (Vous pouvez obtenir de l'aide sur ce site ou sur les forums ESRI, mais c'est loin de leur parler directement.)

Restez au courant des Service Packs et des correctifs. Vous n'êtes pas assuré de n'avoir aucun problème si vous le faites, mais vous pouvez répondre en toute sécurité «Oui», lorsque le support vous demande si vous avez installé la dernière version / les dernières mises à jour.

Contribuez vos solutions de contournement à la communauté (blogs, questions ici, etc.). Si suffisamment de personnes faisaient cela, j'imagine que deux choses se produiraient: un, plus de développeurs seraient conscients des problèmes et auraient une chance de les éliminer plus rapidement et deux, les problèmes seraient résolus plus rapidement par ESRI (rien de tel qu'une loupe) verre pour faire bouger les fourmis, n'est-ce pas?).

Je suis également un développeur ESRI qui se bat constamment avec ce produit au quotidien. Je n'ai pas de support de maintenance, donc je n'ai pas beaucoup de retours des développeurs.

C'est vraiment vraiment très frustrant quand quelque chose "ne marche pas" (par opposition à IJW - ça marche juste), peu importe à quel point vous essayez.

Ce que j'essaie de gagner le combat:

• Poser des questions (beaucoup)
• Lire la référence du SDK ArcObjects (beaucoup - encore et encore)
• Expérimentez avec différentes configurations

Le chemin le plus court vers un résultat consiste à demander à quelqu'un qui a déjà eu le même problème, donc, si quelqu'un a eu ce problème et a trouvé une solution, il vous le dira probablement.

La documentation est bonne, mais manque de descriptions d'éléments clés et de détails importants - alors, revenez à 1.

L'expérimentation fonctionne également. Créez un programme de console et testez-le. Les frameworks de tests unitaires peuvent vous aider à tout faire dans un IDE, mais testez différents scénarios.

La bibliothèque ESRI la plus boguée ou la plus étrange est la géodatabase et peut donner des résultats bizarres, selon les conditions, alors essayez de la maîtriser.

Essayez d'utiliser PostGIS> GeoServer> OpenLayers. Découvrez comment cela fonctionne pour votre équipe.