Aumentare la produttività degli sviluppatori con la piattaforma ArcGIS?

Siamo un piccolo team di sviluppatori .NET. Abbiamo una vasta esperienza GIS e nessuno di noi è nuovo nello sviluppo di software / database o nell'amministrazione di sistema. Abbiamo titoli tecnici e molti anni di esperienza nel settore. Abbiamo partecipato ai vertici degli sviluppatori Esri.

La tecnologia di Esri - principalmente ArcGIS Server, ArcSDE e ArcObjects - svolge un ruolo piccolo ma necessario in tutto il software che sviluppiamo. Nonostante lo status di minoranza di ESRI nel nostro stack tecnologico, dedichiamo una quantità eccessiva di tempo alla risoluzione di bug inafferrabili, alla realizzazione di soluzioni alternative, alla decodifica dei suoi vaghi messaggi di errore, al rilevamento dei problemi di prestazioni e ai processi di riciclaggio.

In genere i nostri problemi derivano da bug autentici, scarsa gestione delle eccezioni, limitazione delle decisioni di progettazione / architettura, mancanza di documentazione, instabilità o una combinazione di questi. (Sto parlando dello stack ESRI qui.)

Dal punto di vista di un project manager, sono molto preoccupato per la produttività del team. Questo ci costa molto tempo. Non abbiamo tempo di apprendere ogni idiosincrasia dello stack ESRI, ma dobbiamo ancora fare le cose. (Non posso vivere con esso, non posso vivere senza di esso.)

Quali suggerimenti pragmatici hai per aumentare la produttività degli sviluppatori con ESRI nel mix?

Non sto cercando suggerimenti su stack tecnologici alternativi.

Per quanto riguarda le prestazioni, sembra che la soluzione migliore sia scrivere codice proxy C ++ su ArcObjects come indicato in questo articolo . Nell'esempio ESRI fornisce la rimozione di un uso intenso dell'interoperabilità COM con un aumento delle prestazioni di 6 volte.

L'ESRI fornisce inoltre suggerimenti / migliori pratiche sulla gestione dei messaggi di errore COM criptici e una spiegazione dei codici di errore HRESULT .

Oltre a questi molti problemi di configurazione sono legati a Windows, e quindi una buona conoscenza della gestione dei server Windows, IIS, servizi Windows, registri eventi di Windows, registro, oggetti COM registrati ecc.

Oltre a questi articoli, esistono alcuni approcci di sviluppo più generici che potresti trovare utili.

Approcci allo sviluppo del software

• Utilizzare i servizi Web il più possibile, per entrambi i dati geografici (WMS, WFS, servizi ArcGIS REST). Questa separazione semplifica il debug e la manutenzione delle cose.
• Ove possibile, installare i sistemi per pulire le installazioni di Windows. Crea script di installazione in modo da poter ricreare l'intero sistema da zero senza dover fare affidamento sulla memoria e sui processi manuali. Le macchine virtuali sono perfette per questo.
• Per quanto possibile, mantenere puri .NET e DLL con codice specifico ESRI separato
• Potresti iniziare a provare a fare più "sollevamento / elaborazione pesante" nel database, ad esempio direttamente in SQL Server 2008 con le nuove classi Geometria e Geografia

Comunicazione

• Pubblica gli elusivi bug su GIS SE / StackOverflow e se trovi anche le soluzioni postali quelli, ho trovato le risposte precedenti che ho scritto io stesso mentre cercavo lo stesso bug che avevo completamente dimenticato circa 6 mesi dopo ..
• Prendi appunti e, idealmente, consenti loro di essere ricercabili da altri membri del team. Ho provato i wiki ma la mancanza di immagini incollate era abbastanza un ostacolo per impedirmi di farlo regolarmente. Attualmente uso Microsoft OneNote che è perfetto per tenere traccia di errori, URL, schermate. Può anche essere condiviso.
• Per approcci tecnici più dettagliati, pubblicali su un blog. Sembra esserci una condivisione di dettagli molto minore nel mondo ESRI, probabilmente a causa del timore che altri possano trarre vantaggio commerciale, tuttavia un blog decente è una buona pubblicità per i servizi della tua azienda

Temo che non ci saranno molte buone risposte da questa domanda. Ma è una buona cosa .... le prestazioni dei prodotti ESRI sono state una mia preoccupazione per qualche tempo.

Il mio commento qui sopra sta interrogando la necessità di prodotti ESRI o puoi migrare verso uno stack tecnologico diverso. Se stai sviluppando con i prodotti ESRI per integrarti con i sistemi ESRI per attirare gli utenti ESRI, allora sei bloccato con una base di codice ESRI che è stata trasferita o contorta per adattarsi alle piattaforme di sviluppo e utente moderne.

Qualcuno di ESRI, per favore, correggimi se sbaglio La maggior parte delle librerie .NET di ESRI sono wrapper per oggetti COM, di cui ci sono spese generali per accedere e offrono ambigui rapporti e gestione migliori degli errori. Comprendere gli oggetti COM sottostanti e il loro coinvolgimento nella tua base di codice ti aiuterà a progettare meglio il tuo codice per adattarlo al loro funzionamento. Questo fatto mi aiuta ad aumentare le prestazioni dei miei script Python di 10 volte. Ciò che una volta impiegava 40 minuti ora ne richiede 4 e con un po 'di modifica ora è sceso a 2,5 minuti!

Ho sentito cose positive con ArcGIS 10, ma non trattenere il respiro.

Se stai usando i prodotti ESRI per fornire una soluzione GIS all'interno del tuo software, allora aggancia uno dei tanti progetti open source offerti e costruisci da lì. @capdragon offre uno di questi set di applicazioni che ti forniranno una grande flessibilità e scalabilità con un team di supporto di sviluppatori affini nel cloud per aiutarti.

Lo sviluppo con i prodotti ESRI è un gioco mentale con ambiguità, oscuri hack e incoerenze dei principali attori se stai cercando di fare qualcosa di innovativo e al di fuori della procedura operativa standard ESRI.

Voglio qualcuno che mi dimostri che ho torto!

Nella mia esperienza di lavoro con ESRI, più lontano puoi allontanarti da ArcObjects, più è probabile che tu abbia successo. In termini pratici, ciò significa che se puoi utilizzare le più recenti API REST per fare ciò che stai facendo, dovresti sempre accedere ad ArcGIS in quel modo.

Sembrano aver imparato qualcosa dall'errore totale che è stato l'ADF Web in Java / .net e le API REST sono molto semplificate e hanno un track record relativamente grande nel lavorare senza troppe complicazioni. Il modo più semplice per accedere all'API REST è se stai lavorando in Javascript / Flex / Silverlight poiché ESRI fornisce librerie per quelli che sono abbastanza buoni, ma è solo un'interfaccia REST standard e puoi parlarci con quasi tutto.

Ci sono cose che non puoi fare in questo modo, ma non posso sottolineare abbastanza quanto sia più bello lavorare con quasi qualsiasi altra cosa nello stack ESRI. Quando devi lavorare con ArcObjects (o ArcObjects .net avvolto), tutto ciò che puoi veramente fare è creare un'ottima documentazione nel tuo codice e pregare che non rompano le cose nella prossima patch (cosa che probabilmente faranno, conoscendole ).

Mantieni aggiornato il tuo supporto tecnico. L'unica cosa più frustrante del cercare di capire un problema con il codice è cercare di capirlo senza l'aiuto delle persone che hanno scritto il codice. E non riceverai alcun aiuto dall'ESRI se non hai un accordo di manutenzione con loro. (Potresti ricevere aiuto da questo sito o dai forum ESRI, ma è molto lontano dal parlare direttamente con loro.)

Rimani aggiornato su service pack e patch. Se non lo fai, non hai la garanzia di non avere problemi, ma puoi tranquillamente rispondere "Sì" quando ti viene chiesto dall'assistenza se hai installato la versione / gli aggiornamenti più recenti.

Contribuisci alle soluzioni alternative per la community (blog, domande qui, ecc.). Se abbastanza persone lo facessero, immagino che accadrebbero due cose: uno, più sviluppatori sarebbero consapevoli dei problemi e avrebbero la possibilità di combattere per eliminarli più rapidamente e due, i problemi verrebbero risolti più rapidamente dall'ESRI (niente come un ingrandimento vetro per far muovere le formiche, vero?).

Sono anche uno sviluppatore ESRI che combatte costantemente con questo prodotto su base giornaliera. Non ho un supporto per la manutenzione, quindi non ricevo molti feedback dagli sviluppatori.

È davvero davvero frustrante quando qualcosa "Just Doesn't Work" (al contrario di IJW - It Just Works), non importa quanto ci provi.

Cosa faccio per vincere il combattimento:

• Poni domande (molto)
• Leggi riferimento SDK ArcObjects (molto - ancora e ancora)
• Sperimenta con diverse configurazioni

Il percorso più breve per un risultato è chiedere a qualcuno che ha già avuto lo stesso problema, quindi, se qualcuno ha avuto quel problema e ha trovato una soluzione, molto probabilmente te lo diranno.

La documentazione è buona, ma manca di descrizioni degli elementi chiave e di dettagli importanti, quindi torna a 1.

Anche la sperimentazione funziona. Creare un programma console e testare via. I framework di unit test possono aiutarti a fare tutto all'interno di un IDE, ma testare diversi scenari.

La più vivace o strana delle librerie ESRI è Geodatabase e può dare risultati bizzarri, a seconda delle condizioni, quindi prova a dominarla.

Prova a utilizzare PostGIS> GeoServer> OpenLayers. Guarda come funziona per il tuo team.