Steigern Sie die Entwicklerproduktivität mit der ArcGIS-Plattform?

Wir sind ein kleines Team von .NET-Entwicklern. Wir haben umfangreiche Erfahrungen mit GIS und keiner von uns ist neu in der Software- / Datenbankentwicklung oder Systemadministration. Wir verfügen über technische Abschlüsse und langjährige Branchenerfahrung. Wir haben an den Esri Developer Summits teilgenommen.

Die Technologie von Esri - hauptsächlich ArcGIS Server, ArcSDE und ArcObjects - spielt in der gesamten von uns entwickelten Software eine kleine, aber notwendige Rolle. Trotz des Minderheitenstatus von ESRI in unserem Technologiestapel verbringen wir übermäßig viel Zeit mit der Behebung schwer zu lösender Fehler, der Behebung von Problemumgehungen, der Entschlüsselung der vagen Fehlermeldungen, der Verfolgung von Leistungsproblemen und der Wiederverwertung von Prozessen.

In der Regel beruhen unsere Probleme auf echten Fehlern, unzureichender Ausnahmebehandlung, eingeschränkten Entwurfs- / Architekturentscheidungen, fehlender Dokumentation, Instabilität oder einer Kombination davon. (Ich spreche hier vom ESRI-Stack.)

Aus Sicht eines Projektmanagers bin ich sehr besorgt über die Produktivität des Teams. Das kostet uns viel Zeit. Wir haben nicht die Zeit, jede Eigenart des ESRI-Stacks zu lernen, aber wir müssen noch einige Dinge erledigen. (Kann nicht damit leben, kann nicht ohne leben.)

Welche pragmatischen Vorschläge haben Sie zur Steigerung der Entwicklerproduktivität mit ESRI im Mix?

Ich suche keine Vorschläge für alternative Technologie-Stacks.

Aus Gründen der Leistung ist es anscheinend die beste Lösung, C ++ - Proxy-Code in ArcObjects zu schreiben, wie in diesem Artikel erwähnt . In dem Beispiel gibt ESRI die Entfernung von starker Nutzung der COM-Interop eine 6-fache Leistungssteigerung.

ESRI gibt auch Vorschläge / Best Practices zum Umgang mit kryptischen COM-Fehlermeldungen - und eine Erläuterung der HRESULT-Fehlercodes .

Darüber hinaus hängen viele Konfigurationsprobleme mit Windows zusammen. Daher sind gute Kenntnisse in Bezug auf Windows-Serververwaltung, IIS, Windows-Dienste, Windows-Ereignisprotokolle, Registrierung, registrierte COM-Objekte usw. hilfreich.

Zusätzlich zu diesen Artikeln gibt es eine Reihe allgemeinerer Entwicklungsansätze, die Sie möglicherweise nützlich finden.

Ansätze der Softwareentwicklung

• Verwenden Sie Web-Services für beide geografischen Daten (WMS, WFS, ArcGIS REST-Services) so oft wie möglich. Diese Trennung erleichtert das Debuggen und Warten.
• Installieren Sie nach Möglichkeit Systeme, um Windows-Installationen zu bereinigen. Erstellen Sie Installationsskripte, damit Sie das gesamte System von Grund auf neu erstellen können, ohne auf Arbeitsspeicher und manuelle Prozesse angewiesen zu sein. Dafür sind virtuelle Maschinen perfekt.
• Halten Sie möglichst reine .NET- und DLL-Dateien mit ESRI-spezifischem Code getrennt
• Mit den neuen Klassen "Geometry" und "Geography" könnten Sie versuchen, mehr "Schweres Heben / Verarbeiten" in der Datenbank durchzuführen, z. B. direkt in SQL Server 2008

Kommunikation

• Veröffentlichen Sie die schwer fassbaren Fehler in GIS SE / StackOverflow, und wenn Sie die entsprechenden Lösungen finden, habe ich frühere Antworten gefunden, die ich selbst geschrieben habe, als ich nach dem gleichen Fehler gesucht habe, den ich 6 Monate später komplett vergessen hatte.
• Machen Sie sich Notizen und lassen Sie sie idealerweise von anderen Teammitgliedern durchsuchen. Ich habe Wikis ausprobiert, aber das Fehlen von Bildern zum Einfügen war schon eine Hürde, um mich davon abzuhalten, es regelmäßig zu tun. Ich verwende derzeit Microsoft OneNote, das perfekt ist, um Fehler, URLs und Screenshots zu verfolgen. Es kann auch geteilt werden.
• Veröffentlichen Sie detailliertere technische Ansätze in einem Blog. Es scheint in der ESRI-Welt weitaus weniger Details auszutauschen, möglicherweise aus Angst, andere könnten kommerzielle Vorteile nutzen. Ein anständiger Blog ist jedoch eine gute Werbung für die Dienste Ihres Unternehmens

Ich befürchte, dass aus dieser Frage nicht viele gute Antworten hervorgehen werden. Aber es ist gut ... Die Leistung von ESRI-Produkten ist mir seit einiger Zeit ein Anliegen.

Mein Kommentar oben ist die Frage, ob ESRI-Produkte benötigt werden oder ob Sie auf einen anderen Technologie-Stack migrieren können. Wenn Sie mit ESRI-Produkten entwickeln, um sie in ESRI-Systeme zu integrieren, um ESRI-Benutzer anzusprechen, müssen Sie eine ESRI-Codebasis verwenden, die für moderne Entwicklungs- und Benutzerplattformen portiert oder verzerrt wurde.

Jemand von ESRI korrigiert mich bitte, wenn ich falsch liege. Die meisten .NET-Bibliotheken von ESRI sind Wrapper für COM-Objekte, von denen es Overheads gibt, auf die zugegriffen werden kann und die bestenfalls zweideutige Fehlerberichte und -behandlungen bieten. Wenn Sie die zugrunde liegenden COM-Objekte und deren Einbeziehung in Ihre Codebasis kennen, können Sie Ihren Code besser auf deren Betrieb abstimmen. Diese eine Tatsache hilft mir, die Leistung in meinen Python-Skripten um das Zehnfache zu steigern. Was früher 40 Minuten gedauert hat, dauert jetzt 4 Minuten und mit ein wenig Feinabstimmung sind es jetzt nur noch 2,5 Minuten!

Ich habe mit ArcGIS 10 gute Dinge gehört, aber halten Sie nicht den Atem an.

Wenn Sie ESRI-Produkte verwenden, um eine GIS-Lösung in Ihrer Software bereitzustellen, können Sie eines der vielen angebotenen Open Source-Projekte nutzen und von dort aus erstellen. @capdragon bietet eine Reihe solcher Anwendungen, die Ihnen ein hohes Maß an Flexibilität und Skalierbarkeit bieten. Ein Support-Team aus gleichgesinnten Entwicklern in der Cloud unterstützt Sie dabei.

Die Entwicklung mit ESRI-Produkten ist ein Spiel des Denkens mit Ambiguität, obskuren Hacks und Inkonsistenzen, das die Hauptakteure sind, wenn Sie versuchen, etwas Innovatives und außerhalb des ESRI-Standard-Betriebsverfahrens zu tun.

Ich möchte jemanden, der mir das Gegenteil beweist!

Nach meiner Erfahrung mit ESRI ist es umso wahrscheinlicher, dass Sie Erfolg haben, je weiter Sie sich von ArcObjects entfernen können. In der Praxis bedeutet dies, dass Sie immer auf diese Weise auf ArcGIS zugreifen sollten, wenn Sie die neueren REST-APIs verwenden können, um das zu tun, was Sie tun.

Sie scheinen etwas aus dem Totalausfall des Web-ADF in Java / .net gelernt zu haben, und die REST-APIs sind stark vereinfacht und haben eine vergleichsweise gute Erfolgsbilanz darin, einfach und ohne großen Aufwand zu arbeiten. Der einfachste Weg, auf die REST-API zuzugreifen, ist, wenn Sie in Javascript / Flex / Silverlight arbeiten, da ESRI Bibliotheken für diejenigen bereitstellt, die ziemlich gut sind, aber es ist nur eine Standard-REST-Schnittstelle, mit der Sie mit fast allem kommunizieren können.

Es gibt Dinge, die man so nicht machen kann, aber ich kann gar nicht genug betonen, wie viel schöner es ist, mit fast allem anderen im ESRI-Stack zu arbeiten. Wenn Sie mit ArcObjects (oder den mit .net umschlossenen ArcObjects) arbeiten müssen, können Sie in Ihrem Code nur eine äußerst gute Dokumentation erstellen und beten, dass sie im nächsten Patch keine Fehler verursachen (was wahrscheinlich der Fall sein wird, wenn Sie sie kennen ).

Halten Sie Ihre Support-Wartung auf dem neuesten Stand. Das einzige, was frustrierender ist, als ein Code-Problem herauszufinden, ist, es ohne Hilfe der Leute herauszufinden, die den Code geschrieben haben. Und Sie erhalten keinerlei Hilfe von ESRI, wenn Sie keinen Wartungsvertrag mit ihnen haben. (Möglicherweise erhalten Sie Hilfe von dieser Website oder den ESRI-Foren, aber das ist weit davon entfernt, direkt mit ihnen zu sprechen.)

Bleiben Sie auf dem Laufenden über Service Packs und Patches. Sie haben in diesem Fall garantiert keine Probleme, können aber sicher mit "Ja" antworten, wenn Sie vom Support gefragt werden, ob Sie die neueste Version / die neuesten Updates installiert haben.

Tragen Sie Ihre Problemumgehungen zur Community bei (Blogs, Fragen hier usw.). Wenn genug Leute das tun würden, stünden mir zwei Dinge bevor: Erstens, mehr Entwickler würden sich der Probleme bewusst sein und hätten die Chance, sie schneller auszumerzen, und zweitens, Probleme würden durch ESRI schneller behoben (nichts wie eine Vergrößerung) Glas, um die Ameisen zum Laufen zu bringen?

Ich bin auch ein ESRI-Entwickler, der täglich mit diesem Produkt kämpft. Ich habe keinen Wartungssupport, daher bekomme ich von den Entwicklern nicht viel Feedback.

Es ist wirklich sehr, sehr frustierend, wenn etwas "einfach nicht funktioniert" (im Gegensatz zu IJW - Es funktioniert einfach), egal wie sehr Sie es versuchen.

Was ich versuche, um den Kampf zu gewinnen:

• Fragen stellen (viel)
• Lesen Sie die ArcObjects SDK-Referenz (viel - immer und immer wieder)
• Experimentieren Sie mit verschiedenen Einstellungen

Der kürzeste Weg zu einem Ergebnis besteht darin, jemanden zu fragen, der bereits dasselbe Problem hatte. Wenn also jemand in dieses Problem geriet und eine Lösung fand, wird er es Ihnen höchstwahrscheinlich mitteilen.

Die Dokumentation ist gut, aber es fehlen wichtige Elementbeschreibungen und wichtige Details. Kehren Sie zu 1 zurück.

Das Experimentieren funktioniert auch. Erstellen Sie ein Konsolenprogramm und testen Sie es. Unit Testing Frameworks können Ihnen dabei helfen, alles in einer IDE zu tun, aber Sie können verschiedene Szenarien testen.

Die fehlerhafteste oder seltsamste ESRI-Bibliothek ist Geodatabase und kann je nach den Bedingungen bizarre Ergebnisse liefern. Versuchen Sie also, sie zu meistern.

Versuchen Sie es mit PostGIS> GeoServer> OpenLayers. Sehen Sie, wie das für Ihr Team funktioniert.