¿Aumentar la productividad de los desarrolladores con la plataforma ArcGIS?

Question

Somos un pequeño equipo de desarrolladores .NET. Tenemos amplia experiencia en SIG, y ninguno de nosotros es nuevo en el desarrollo de software/base de datos ni en la administración de sistemas. Tenemos títulos técnicos y muchos años de experiencia en el sector. Hemos asistido a las cumbres de desarrolladores de Esri.

La tecnología de Esri -principalmente ArcGIS Server, ArcSDE y ArcObjects- desempeña un papel pequeño pero necesario en todo el software que desarrollamos. A pesar del estatus minoritario de ESRI en nuestra pila tecnológica, pasamos una cantidad desmesurada de tiempo solucionando fallos escurridizos, elaborando soluciones, descifrando sus vagos mensajes de error, rastreando problemas de rendimiento y reciclando procesos.

Por lo general, nuestros problemas provienen de errores genuinos, mala gestión de excepciones, decisiones de diseño/arquitectónicas limitantes, falta de documentación, inestabilidad o alguna combinación de todo ello. (Me refiero a la pila de ESRI).

Desde la perspectiva de un gestor de proyectos, me preocupa mucho la productividad del equipo. Esto nos cuesta mucho tiempo. No tenemos tiempo para aprender cada idiosincrasia de la pila ESRI, pero aun así tenemos que hacer las cosas. (No se puede vivir con ello, no se puede vivir sin ello).

¿Qué sugerencias pragmáticas tiene para aumentar la productividad de los desarrolladores con ESRI de por medio?

No busco sugerencias sobre pilas tecnológicas alternativas.

Answer 1

Para el rendimiento parece que la mejor solución es escribir código proxy C ++ para ArcObjects como se menciona en este artículo . En el ejemplo de ESRI, la eliminación del uso intensivo de la interoperabilidad COM multiplica por 6 el rendimiento.

ESRI también ofrece sugerencias y buenas prácticas sobre gestión de los crípticos mensajes de error COM - y una explicación de Códigos de error HRESULT .

Además, gran parte de los problemas de configuración están relacionados con Windows, por lo que un buen conocimiento de la gestión de servidores Windows, IIS, los servicios de Windows, los registros de eventos de Windows, el registro, los objetos COM registrados, etc., son de gran ayuda.

Además de estos artículos, hay una serie de enfoques de desarrollo más genéricos que pueden resultarle útiles.

Enfoques de desarrollo de software

• Utilizar los servicios web en la medida de lo posible, tanto para los datos geográficos (WMS,WFS,ArcGIS REST services). Esta separación facilita la depuración y el mantenimiento.
• Siempre que sea posible, instale sistemas para limpiar las instalaciones de Windows. Cree scripts de instalación para poder recrear todo el sistema desde cero sin tener que depender de la memoria y los procesos manuales. Las máquinas virtuales son perfectas para esto.
• En la medida de lo posible, mantenga separados .NET puro y las DLL con código específico de ESRI.
• Podría empezar a intentar hacer más "trabajo pesado / procesamiento" en la base de datos, por ejemplo, directamente en SQL Server 2008 con las nuevas clases Geometría y Geografía.

Comunicación

• Publica los errores elusivos en GIS SE / StackOverflow, y si encuentras las soluciones publícalas también, he encontrado respuestas anteriores que he escrito yo mismo mientras buscaba el mismo error del que me había olvidado por completo 6 meses después
• Guarda notas y, a ser posible, permite que otros miembros del equipo puedan buscarlas. He probado las wikis, pero la imposibilidad de pegar imágenes era un obstáculo suficiente para dejar de utilizarlas con regularidad. Actualmente utilizo Microsoft OneNote, que es perfecto para anotar errores, URL y capturas de pantalla. También se puede compartir.
• Para planteamientos técnicos más detallados, publícalos en un blog. Parece que en el mundo ESRI se comparten menos los detalles, posiblemente por miedo a que otros se aprovechen comercialmente, pero un blog decente es una buena publicidad para los servicios de tu empresa.

Answer 2

Me temo que de esta pregunta no van a salir muchas respuestas buenas. Pero es una buena pregunta: .... El rendimiento de los productos ESRI es una de mis preocupaciones desde hace tiempo.

Mi comentario anterior se refiere a la necesidad de los productos ESRI o puede migrar a una pila de tecnología diferente. Si estás desarrollando con productos ESRI para integrarlos con sistemas ESRI y atraer a los usuarios de ESRI, entonces estás atascado con una base de código ESRI que ha sido portado o contorsionado para adaptarse a las plataformas modernas de desarrollo y de usuario.

Que alguien de ESRI me corrija si me equivoco La mayoría de las bibliotecas .NET de ESRI son envoltorios de objetos COM, cuyo acceso conlleva gastos generales y que ofrecen, en el mejor de los casos, informes y gestión de errores ambiguos. Comprender los objetos COM subyacentes y su implicación en tu base de código te ayudará a diseñar mejor tu código para que se adapte a su funcionamiento. Este hecho me ayudó a multiplicar por 10 el rendimiento de mis scripts en Python. Lo que antes tardaba 40 minutos ahora tarda 4 y con un poco de ajuste ¡ahora se reduce a 2,5 minutos!

He oído cosas buenas de ArcGIS 10, pero no contenga la respiración.

Si utiliza productos ESRI para proporcionar una solución SIG dentro de su software, únase a uno de los muchos proyectos de código abierto que se ofrecen y construya a partir de ahí. @capdragon ofrece un conjunto de aplicaciones que le proporcionarán una gran flexibilidad y escalabilidad con un equipo de apoyo de desarrolladores afines en la nube para ayudarle.

El desarrollo con productos ESRI es un juego mental en el que la ambigüedad, los trucos oscuros y la incoherencia son los principales protagonistas si intentas hacer algo innovador y fuera del procedimiento operativo estándar de ESRI.

¡Quiero que alguien me demuestre lo contrario!

Answer 3

En mi experiencia trabajando con ESRI, cuanto más te alejes de ArcObjects, más probabilidades tendrás de tener éxito. En términos prácticos, eso significa que si usted puede utilizar las nuevas API REST para hacer lo que estás haciendo, siempre se debe acceder a ArcGIS de esa manera.

Parece que han aprendido algo del fracaso total que supuso el Web ADF en Java/.net, y las API REST están mucho más simplificadas y tienen un historial comparativamente bueno en lo que se refiere a funcionar sin muchas complicaciones. La forma más sencilla de acceder a la API REST es si usted está haciendo el trabajo en Javascript / Flex / Silverlight como ESRI proporciona bibliotecas para los que son bastante buenos, pero es sólo una interfaz REST estándar y se puede hablar con él con casi cualquier cosa.

Hay cosas que no se pueden hacer de esa manera, pero no puedo dejar de recalcar lo mucho más agradable que es trabajar con él que con casi cualquier otra cosa de la pila ESRI. Cuando tienes que trabajar con ArcObjects (o el .net envuelto ArcObjects), todo lo que realmente puede hacer es crear muy buena documentación en su código y rezar para que no se rompen cosas en el próximo parche (que probablemente lo hará, conociéndolos).

Answer 4

Mantenga al día su mantenimiento de asistencia. Lo único más frustrante que tratar de resolver un problema de código es tratar de resolverlo sin ayuda de las personas que escribieron el código. Y no recibirás ningún tipo de ayuda de ESRI si no tienes un acuerdo de mantenimiento con ellos. (Puede que consigas algo de ayuda en este sitio o en los foros de ESRI, pero eso está muy lejos de hablar directamente con ellos).

Manténgase al día de los paquetes de servicios y parches. No está garantizado que tenga no si lo hace, pero puede responder con seguridad "Sí" cuando el servicio de asistencia le pregunte si tiene instalada la última versión/actualización.

Aporta tus soluciones a la comunidad (blogs, preguntas aquí, etc.). Si un número suficiente de personas lo hiciera, imagino que ocurrirían dos cosas: en primer lugar, más desarrolladores estarían al tanto de los problemas y tendrían más posibilidades de solucionarlos más rápidamente y, en segundo lugar, ESRI solucionaría los problemas con mayor rapidez (no hay nada como una lupa para que se muevan las hormigas, ¿verdad?).

Answer 5

También soy un desarrollador de ESRI que lucha constantemente con este producto a diario. No tengo soporte de mantenimiento, por lo que no recibo muchos comentarios de los desarrolladores.

Es realmente frustrante cuando algo "simplemente no funciona" (en contraposición a IJW - It Just Works), por mucho que lo intentes.

Lo que hago es intentar ganar el combate:

• Hacer preguntas (muchas)
• Lea la referencia del SDK de ArcObjects (mucho, una y otra vez).
• Experimente con diferentes configuraciones

El camino más corto para llegar a un resultado es preguntar a alguien que ya haya tenido el mismo problema, así que, si alguien tuvo ese problema y encontró una solución, lo más probable es que te lo diga.

La documentación es buena, pero le faltan descripciones de elementos clave y detalles importantes, así que vuelva a la 1.

La experimentación también funciona. Crea un programa de consola y haz pruebas. Los frameworks de Unit Testing pueden ayudarte a hacer todo dentro de un IDE, pero probando diferentes escenarios.

La librería de ESRI con más errores o más rara es Geodatabase y puede dar resultados extraños, dependiendo de las condiciones, así que intenta dominarla.