Надлежащее использование Grails, Rails и т. Д.?

Question

У нас есть электронная таблица Excel, распространяющаяся прямо сейчас (по всему миру) в моей компании, чтобы собрать различную информацию о применении технологий в каждой стране. Проблема в том, что он выходит, получает изменения, но они никогда не бывают очевидными и часто противоречивы - и тогда мы должны разбить их вместе. Для меня рабочая книга - не более чем приложение типа «мусор в / мусор», ожидающее написания.

В компании, у которой достаточно персонала и знаний для того, чтобы по какой-то причине посвятить себя корпоративным проектам, гибкие и языковые / фреймворки, такие как Rails, Grails и т. Д., Не одобряются. Тем не менее, я не могу не думать, что это почти идеально подходит для нужд, учитывая особенности лесов для чрезвычайно простых реализаций захвата необработанных полей с помощью только нескольких поисков (то есть предварительно определенной категории). Я думаю, что это будет считаться очень подходящим использованием этих структур.

Кто-нибудь с успехом работал над такими быстрыми и грязными приложениями в обычно крупных и жестких корпоративных средах? Какие-нибудь подсказки для того, чтобы сообщить эту потребность / уместность нетехническому управлению?

Answer 1

Единственный способ реализовать это в жесткой организации - это заставить ее работать и продемонстрировать ее - без одобрения.Руководству очень сложно сказать «нет» готовому проекту.

Answer 2

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

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

Корпорации много раз были укушены в прошлом и осторожны при внедрении новых технологий.

Таким образом, если вы сможете собрать больше людей, чтобы изучать Ruby / Rails в своей группе (или где-либо еще в вашей компании), вы, возможно, сможете обосновать это. В противном случае, к сожалению, вам лучше реализовать что-то на Sharepoint: - (.

Answer 3

Если у вас уже есть инфраструктура Java, создание приложения Grails практически не потребует дополнительных ИТ-ресурсов для поддержки и поддержки.Затраты и усилия на поддержку и обслуживание должны быть такими же, как и для приложения Java (т. Е. Приложения Grails работают на Tomcat, используют ту же JVM, используют те же инструменты диагностики / профилирования и т. Д.).

По моему опыту, более крупным ИТ-организациям сложнее поддерживать Ruby, когда его еще нет в наборе инструментов, поскольку он представляет собой новый язык, новую среду развертывания и требует значительного объема поддержки и обслуживания.

Я бы разработал минимальный жизнеспособный продукт, а затем подружился с кем-то из ИТ-специалистов, который может помочь вам развернуть его в промежуточной или производственной среде.Тогда заставьте нескольких пользователей сесть на борт и протестировать его, как бета-продукт.После этого откройте его для более широкой аудитории.

Так что, как уже говорили другие, прощайте, а не разрешайте, но будьте осторожны с воздействием на ИТ-организацию.