¿Incrementa la productividad del desarrollador con la plataforma ArcGIS?

20

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 o en la administración del sistema. Tenemos títulos técnicos y muchos años de experiencia en la industria. Hemos asistido a Esri Developer Summits.

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 estado minoritario de ESRI en nuestra pila de tecnología, dedicamos una cantidad de tiempo excesiva a la solución de problemas, elaboramos soluciones, desciframos sus vagos mensajes de error, rastreamos problemas de rendimiento y procesos de reciclaje.

Por lo general, nuestros problemas provienen de errores genuinos, manejo deficiente de excepciones, decisiones de diseño / arquitectura limitantes, falta de documentación, inestabilidad o alguna combinación de ellos. (Estoy hablando de la pila de ESRI aquí.)

Desde la perspectiva de un gerente de proyecto, estoy muy preocupado por la productividad del equipo. Esto nos cuesta mucho tiempo. No tenemos tiempo para aprender cada idiosincrasia de la pila de ESRI, pero aún necesitamos hacer las cosas. (No puedo vivir con eso, no puedo vivir sin él).

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

No estoy buscando sugerencias sobre pilas de tecnología alternativa.

    
pregunta nw1 05.05.2011 - 16:41

6 respuestas

10

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

ESRI también brinda sugerencias / mejores prácticas en manejo de la críptica Mensajes de error COM - y una explicación de error de HRESULT códigos .

Más allá de estos muchos de los problemas de configuración están relacionados con Windows, por lo que un buen conocimiento de la administración del servidor de Windows, IIS, servicios de Windows, registros de eventos de Windows, registro, objetos COM registrados, etc., todos ayudan.

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

  • Use los servicios web tanto como sea posible, para ambos datos geográficos (servicios WMS, WFS, ArcGIS REST). Esta separación hace que las cosas sean más fáciles de depurar y mantener.
  • Donde 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 los archivos .NET y DLL puros con el código específico de ESRI por separado
  • Podría comenzar a intentar hacer más "trabajo pesado / procesamiento" en la base de datos, por ejemplo. directamente en SQL Server 2008 con las nuevas clases de Geometría y Geografía

Comunicación

  • Publique los errores evasivos en GIS SE / StackOverflow, y si encuentra las soluciones también, encontré respuestas anteriores que escribí yo mismo mientras buscaba el mismo error que había olvidado por completo unos 6 meses después. .
  • Mantenga notas, e idealmente permita que otras personas del equipo puedan buscarlas. He intentado con los wikis, pero la falta de pegar imágenes fue un obstáculo suficiente para que dejara de hacerlo con regularidad. Actualmente utilizo Microsoft OneNote, que es perfecto para realizar un seguimiento de errores, URL y capturas de pantalla. Puede ser compartido también.
  • Para enfoques técnicos más detallados, publíquelos en un blog. Parece que hay mucho menos intercambio de detalles en el mundo de ESRI, posiblemente debido al temor de que otros aprovechen las ventajas comerciales, sin embargo, un blog decente es un buen anuncio para los servicios de su empresa
respondido por el geographika 05.05.2011 - 17:57
7

Me temo que de esta pregunta no surgirán muchas respuestas buenas. Pero es una buena ... el rendimiento de los productos de ESRI ha sido una preocupación mía durante algún tiempo.

Mi comentario anterior está consultando la necesidad de productos ESRI o puede migrar a una pila de tecnología diferente. Si está desarrollando con productos de ESRI para integrarse con los sistemas de ESRI para atraer a los usuarios de ESRI, entonces está atascado con una base de código de ESRI que ha sido portada o contorsionada para adaptarse al desarrollo moderno y las plataformas de usuario.

Alguien de ESRI, corríjame si me equivoco La mayoría de las bibliotecas .NET de ESRI son envoltorios para objetos COM, de los cuales hay gastos generales para acceder y ofrecer, de forma ambigua, informes de errores y manejo. Comprender los objetos COM subyacentes y su participación en su base de código lo ayudará a diseñar mejor su código para que se adapte a su funcionamiento. Este hecho me ayudó a aumentar el rendimiento en mis scripts de Python 10 veces. ¡Lo que antes tardaba 40 minutos ahora toma 4 y con un poco de ajuste ahora se ha reducido a 2,5 minutos!

He escuchado cosas buenas con ArcGIS 10, pero no aguantes la respiración.

Si está utilizando productos ESRI para proporcionar una solución GIS dentro de su software, entonces seleccione uno de los muchos proyectos de código abierto que se ofrecen y construya desde allí. @capdragon ofrece un conjunto de aplicaciones de este tipo que le brindará una gran cantidad de flexibilidad y escalabilidad con un equipo de soporte de desarrolladores afines en la nube para ayudarlo a avanzar.

El desarrollo con productos ESRI es un juego de campo mental con ambigüedad, trucos ocultos e inconsistencia entre los jugadores principales si está intentando hacer algo innovador y fuera del Procedimiento Operativo Estándar de ESRI.

¡Quiero que alguien me demuestre que estoy equivocado!

    
respondido por el OptimizePrime 05.05.2011 - 17:54
7

En mi experiencia de trabajo con ESRI, cuanto más lejos pueda alejarse de ArcObjects, más probabilidades tendrá de tener éxito. En términos prácticos, eso significa que si puede usar las API REST más recientes para hacer lo que está haciendo, siempre debe acceder a ArcGIS de esa manera.

Parece que aprendieron algo del fallo total que fue el ADF web en Java / .net, y las API REST están mucho más simplificadas y tienen un historial relativamente bueno al trabajar sin mucho problema. La forma más sencilla de acceder a la API REST es si está trabajando en Javascript / Flex / Silverlight, ya que ESRI proporciona bibliotecas para aquellos que son bastante buenos, pero es solo una interfaz REST estándar y puede hablar con casi cualquier cosa.

Hay cosas que no puedes hacer de esa manera, pero no puedo enfatizar lo agradable que es trabajar con casi cualquier otra cosa en la pila de ESRI. Cuando tienes que trabajar con ArcObjects (o con .NET envuelto ArcObjects), todo lo que puedes hacer es crear una documentación extremadamente buena en tu código y rezar para que no rompan cosas en el próximo parche (que probablemente lo harán, sabiéndolos). ).

    
respondido por el Tridus 05.05.2011 - 23:06
6

Mantenga actualizado su mantenimiento de soporte. Lo único más frustrante que tratar de resolver un problema de código es tratar de resolverlo sin la ayuda de las personas que escribieron el código. Y no recibirá ninguna ayuda de ESRI si no tiene un acuerdo de mantenimiento con ellos. (Es posible que recibas ayuda de este sitio o de los foros de ESRI, pero eso está muy lejos de hablar directamente con ellos).

Mantente al tanto de los paquetes de servicios y parches. No se garantiza que tenga problemas con no si lo tiene, pero puede responder de manera segura, "Sí", cuando el servicio de asistencia le pregunte si tiene la última versión / actualizaciones instaladas.

Contribuya sus soluciones a la comunidad (blogs, preguntas aquí, etc.). Si suficiente gente hiciera eso, me imagino que sucederían dos cosas: uno, más desarrolladores estarían al tanto de los problemas y tendrían una oportunidad de pelear para eliminarlos más rápidamente y dos, los problemas se arreglarían más rápido con ESRI (nada como una lupa) vidrio para poner en movimiento a las hormigas, ¿verdad?).

    
respondido por el Michael Todd 05.05.2011 - 17:49
4

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.

Realmente es realmente frustrante cuando algo "simplemente no funciona" (a diferencia de IJW - Simplemente funciona), no importa cuánto lo intentes.

Lo que intento ganar la pelea:

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

El camino más corto hacia un resultado es preguntar a alguien que ya tenía el mismo problema, por lo tanto, si alguien se metió en ese problema y encontró una solución, lo más probable es que se lo diga.

La documentación es buena, pero carece de descripciones de elementos clave y detalles importantes, por lo tanto, vuelva al 1.

La experimentación también funciona. Crea un programa de consola y prueba. Los marcos de Unit Testing pueden ayudarlo a hacer todo dentro de un IDE, pero probar diferentes escenarios.

La biblioteca de ESRI con errores o más extraña es la Geodatabase y puede dar resultados extraños, según las condiciones, así que trata de dominarla.

    
respondido por el George Silva 05.05.2011 - 22:39
1

Prueba a usar PostGIS > GeoServer > OpenLayers. Vea cómo funciona eso para su equipo.

    
respondido por el CaptDragon 05.05.2011 - 17:37

Lea otras preguntas en las etiquetas