Повышение производительности труда разработчиков с платформой ArcGIS?

Мы небольшая команда разработчиков .NET. Мы обладаем достаточным опытом работы с ГИС, и никто из нас не является новичком в разработке программного обеспечения / баз данных или системном администрировании. У нас есть технические степени и многолетний опыт работы в отрасли. Мы посетили саммит разработчиков Esri.

Технология Esri, в первую очередь ArcGIS Server, ArcSDE и ArcObjects, играет небольшую, но необходимую роль во всем программном обеспечении, которое мы разрабатываем. Несмотря на меньший статус ESRI в нашем технологическом стеке, мы тратим непомерное количество времени на устранение неуловимых ошибок, нахождение обходных путей, расшифровку его расплывчатых сообщений об ошибках, отслеживание проблем с производительностью и процессы переработки.

Как правило, наши проблемы связаны с подлинными ошибками, плохой обработкой исключений, ограничением проектных / архитектурных решений, отсутствием документации, нестабильностью или некоторой их комбинацией. (Я говорю о стеке ESRI здесь.)

С точки зрения менеджера проекта, я очень обеспокоен продуктивностью команды. Это стоит нам много времени. У нас нет времени, чтобы изучить каждую особенность стека ESRI, но нам все еще нужно добиться своей цели. (Не могу жить с этим, не могу жить без него.)

Какие прагматичные предложения вы предлагаете для повышения производительности труда разработчиков с помощью ESRI?

Я не ищу предложений по альтернативным технологиям стеков.

Для повышения производительности кажется, что лучшим решением является написание прокси-кода C ++ в ArcObjects, как упоминалось в этой статье . В этом примере ESRI дает удаление интенсивного использования взаимодействия COM дает 6-кратное увеличение производительности.

ESRI также дает предложения / лучшие практики по обработке загадочных сообщений об ошибках COM - и объяснение кодов ошибок HRESULT .

Помимо этого, многие проблемы конфигурации связаны с Windows, поэтому полезны хорошие знания об управлении сервером Windows, IIS, службах Windows, журналах событий Windows, реестре, зарегистрированных объектах COM и т. Д.

В дополнение к этим статьям существует ряд более общих подходов к разработке, которые могут оказаться полезными.

Подходы к разработке программного обеспечения

• Максимально используйте веб-сервисы для обеих географических данных (сервисы WMS, WFS, ArcGIS REST). Такое разделение облегчает отладку и обслуживание.
• По возможности устанавливайте системы для очистки установок Windows. Создайте сценарии установки, чтобы вы могли воссоздать всю систему с нуля, не полагаясь на память и ручные процессы. Виртуальные машины идеально подходят для этого.
• В максимально возможной степени сохраняйте чистыми .NET и DLL с отдельным кодом ESRI отдельно
• Вы можете начать пытаться выполнять больше «тяжелой работы / обработки» в базе данных, например, непосредственно в SQL Server 2008 с новыми классами Geometry и Geography.

связь

• Публикуйте неуловимые ошибки в GIS SE / StackOverflow, и если вы найдете решения, которые публикуют их тоже, я найду предыдущие ответы, которые я сам написал, в процессе поиска той же ошибки, которую я полностью забыл спустя 6 месяцев.
• Делайте заметки и в идеале позволяйте их искать в команде. Я пробовал вики, но отсутствие вставки изображений было достаточным препятствием, чтобы мешать мне делать это регулярно. В настоящее время я использую Microsoft OneNote, который идеально подходит для отслеживания ошибок, URL-адресов, скриншотов. Это может быть также поделено.
• Для более подробных технических подходов опубликуйте их в блоге. Похоже, что в мире ESRI гораздо меньше обмена подробностями, возможно, из-за страха, что другие воспользуются коммерческой выгодой, однако приличный блог - хорошая реклама для услуг вашей компании.

Боюсь, на этот вопрос не так много хороших ответов. Но это хорошо ... производительность продуктов ESRI была моей проблемой в течение некоторого времени.

Мой комментарий выше запрашивает потребность в продуктах ESRI или вы можете перейти на другой технологический стек. Если вы разрабатываете продукты ESRI для интеграции с системами ESRI для пользователей ESRI, то вы застряли на базе кода ESRI, которая была перенесена или искажена для соответствия современным разработкам и пользовательским платформам.

Кто-то из ESRI, пожалуйста, исправьте меня, если я ошибаюсь. Большинство .NET-библиотек ESRI являются оболочками для COM-объектов, из-за которых существуют издержки для доступа и предлагают неоднозначные в лучшем случае отчеты об ошибках и их обработку. Понимание базовых COM-объектов и их участия в вашей кодовой базе поможет вам лучше спроектировать ваш код в соответствии с их работой. Этот факт помогает мне увеличить производительность в моих скриптах Python в 10 раз. То, что раньше занимало 40 минут, теперь занимает 4, а с небольшими изменениями - теперь до 2,5 минут!

Я слышал хорошие вещи с ArcGIS 10, но не затаив дыхание.

Если вы используете продукты ESRI для предоставления ГИС-решения в своем программном обеспечении, тогда выберите один из множества предлагаемых проектов с открытым исходным кодом и создайте его оттуда. @capdragon предлагает один из таких наборов приложений, которые обеспечат вам большую гибкость и масштабируемость, а команда поддержки единомышленников в облаке поможет вам в этом.

Разработка с использованием продуктов ESRI - это игра, основанная на разумности, неопределенности, непонятных хакерских способностях и непоследовательности основных игроков, если вы пытаетесь сделать что-то инновационное и выходящее за рамки стандартной операционной процедуры ESRI.

Я хочу, чтобы кто-то доказал меня неправильно!

По моему опыту работы с ESRI, чем дальше вы можете уйти от ArcObjects, тем выше вероятность успеха. С практической точки зрения это означает, что если вы можете использовать более новые API REST для того, чтобы делать то, что вы делаете, вы всегда должны обращаться к ArcGIS таким образом.

Похоже, они чему-то научились из полного отказа, который был у Web ADF в Java / .net, и API-интерфейсы REST значительно упрощены и имеют сравнительно большой послужной список, просто работая без особых хлопот. Самый простой способ получить доступ к REST API - это если вы выполняете работу в Javascript / Flex / Silverlight, поскольку ESRI предоставляет библиотеки для довольно хороших библиотек, но это всего лишь стандартный интерфейс REST, и вы можете общаться с ним практически с чем угодно.

Есть вещи, которые вы не можете сделать таким образом, но я не могу не подчеркнуть, насколько приятнее работать с почти всем остальным в стеке ESRI. Когда вам приходится работать с ArcObjects (или ArcObjects с оболочкой .net), все, что вы действительно можете сделать, это создать чрезвычайно хорошую документацию в вашем коде и молиться, чтобы они не ломали вещи в следующем патче (что они, вероятно, знают, зная их). ).

Поддерживайте вашу поддержку в актуальном состоянии. Единственное, что расстраивает больше, чем пытаться понять проблему с кодом, это пытаться понять это без помощи людей, которые написали код. И вы не получите никакой помощи от ESRI, если у вас нет соглашения об обслуживании с ними. (Вы можете получить некоторую помощь от этого сайта или форумов ESRI, но это далеко от того, чтобы общаться с ними напрямую.)

Будьте в курсе пакетов обновления и исправлений. Вы не гарантируете, что у вас не возникнет никаких проблем, но вы можете смело ответить «Да» на вопрос службы поддержки, если у вас установлена ​​последняя версия / обновления.

Внесите свои обходные пути в сообщество (блоги, вопросы здесь и т. Д.). Если бы достаточное количество людей сделало это, я представляю, что произойдут две вещи: во-первых, больше разработчиков будут осведомлены о проблемах и получат шансы на их быстрое устранение, а во-вторых, проблемы будут исправлены ESRI быстрее (ничего, кроме увеличения стекло, чтобы заставить муравьев двигаться, не так ли?).

Я также разработчик ESRI, который постоянно борется с этим продуктом на ежедневной основе. У меня нет технической поддержки, поэтому я не получаю много отзывов от разработчиков.

Это действительно очень расстраивает, когда что-то "просто не работает" (в отличие от IJW - это просто работает), независимо от того, как сильно вы пытаетесь.

Что я пытаюсь выиграть в бою:

• Задавать вопросы (много)
• Читать справочник ArcObjects SDK (много-много раз)
• Экспериментируйте с разными настройками

Кратчайший путь к результату - спросить кого-то, у кого уже была такая же проблема, поэтому, если кто-то попал в эту проблему и нашел решение, он, скорее всего, скажет вам.

Документация хорошая, но в ней отсутствуют описания ключевых элементов и важные детали - так что вернитесь к 1.

Экспериментирование тоже работает. Создайте консольную программу и протестируйте ее. Фреймворки модульного тестирования могут помочь вам сделать все внутри IDE, но протестировать разные сценарии.

Баггист или самая странная из библиотек ESRI - это база геоданных, которая может давать странные результаты в зависимости от условий, поэтому попытайтесь освоить ее.

Попробуйте использовать PostGIS> GeoServer> OpenLayers. Посмотрите, как это работает для вашей команды.