Очень круто! Действительно Idea очень сильно завязана на Swing. Много было разговоров по поводу Cloud IDE, которая должна будет четко разделять функционал фронтэнда и бэкэнда, но по-моему вся идея заглохла.
А не смотрели в сторону более легких решений на подобие http://creamtec.com/products/ajaxswing/index.html? Это что-то типа RDP на базе Graphics2D и Canvas.
Следующий шаг — обязать всех ходить через прокси провайдера, который будет внаглую подменять сертификаты ssl, а чтобы браузер не ругался, обязать установить в браузере "их" certificate autority.
Все-таки надо различать пользователей, которые пишут библиотеки/фреймворки от тех, кто пишет бизнес логику. Первых очень немного, и они как правило вкурсе всевозможных оптимизаций. Вторых большинство, и они уже используют оптимизированные (или не очень) библиотеки для реализации своих задач.
Поэтому если у вас BigData и вам приходится перелопачивать мегатонны, то скорей всего вы плохо используете данную технологию: там как правило уже есть встроенные оптимизированные средства перелопачивания ввиде Hive, Spark или KSQL. В итоге бизнес работает с уже перелопаченной выжимкой, где особая оптимизация не нужна.
И да, иногда покупка нового сервера обходится дешевле, чем затраты на оптимизацию, проверку и поддержку кода.
Неужели у кого-то реально проект из-за того, что он неправильно пользовал StringBuilder или stream вместо for? В 95% случаев всегда тормозит база данных, причем в половине случаев решение не такое тривиальное, как просто переписать запросы: требуются серьезные архитектурные модификации, использование кешей и т.д. Кроме того, на продакшне ситуация может сильно отличаться от тестового бенча, поэтому всякие профайлеры тут не помогут. Поэтому совет один — используйте лайв мониторинг и фреймворки типа Metrics, пишите понятный код и не сильно забивайте голову всей этой фигней по поводу stream/for, StringBuilder, etc...
Дык, захардкодьте весь дефолтный конфиг значениями прямо в бинах, как я показал выше. А в xml нужно будет прописывать только элементы, значения которых отличаются. JAXB будет создавать объект с дефолтными параметрами, и перезаписывать только поля, указанные в xml. В идеале с пустым xml будет создаваться полный дефолтный конфиг.
Меня всегда интересовал вопрос, как правильно поставить процесс разработки и тестирования в приложении с OSGi-контейнером? Модуль после каждого изменения приходится запаковывать и передеплоивать. Кроме того нет возможности стартануть контейнер из workspace с подцепленным classpath модуля, соответственно невозможно будет дебажить в IDE, или делать hot replace. Даже в JEE есть такие средства как Arquillian, OpenEJB, Microprofile, которые сильно упрощают разработку...
Не совсем понял, что вы имеете ввиду под "наследованием" конфигов. Если это наследование бинов, то у JAXB с этим проблем нет. А если дефолтные значения для полей, то их можно указывать прямо при описании самих полей:
public class DatabaseConfig {
public String url = "jdbc:h2:mem:test";
public String username = "sa";
public String password = "";
}
Да полно. Вот очень неплохой вариант: http://owner.aeonbits.org/.
Для себя я уже давно решил проблему конфигов: использую стандартный JAXB. Структура описывается прямо в бинах при помощи парочки аннотаций. Все сериализуется в XML. Maven автоматически генерит XSD, который понимает IDE и позволяет делать autocomplete при редактировании конфига.
«Цифровая экономика Российской Федерации» — это все правильно и хорошо. Однако возникает вопрос об экономической целесообразности данной программы. Выражаясь простым языком, на программу будут потрачены серьезные государственные средства, но нигде даже не оговариваются способы возврата инвестиций. Из программы понятно, что:
Основным бенефициаром программы являются государственные органы, однако программа не ставит самой целью какую-либо экономию средств или повышение эффективности работы госаппарата (про это не сказано ни слова).
Четко просматривается цель — сбор данных и контроль над деятельностью. Однако мотивация нигде не раскрыта: уменьшение числа преступлений, повышение налоговых сборов и ликвидация черных денег, мониторинг эффективности работы госаппарата, etc...
Нигде не упомянуты интересы и нужды частного бизнеса при реализации программы, что странно. Любая государственная программа первой целью должна ставить интересы физических и юридических лиц.
В программе нет ничего про создание конкурентноспособных информационных технологий и выхода на международный рынок. Кто еще, кроме самого государства, будет покупать разработки? На чем планируется возврат инвестиций?
Опять поиски серебряной пули. Не существует универсального метода написания кода и разбивки на части. Всегда любым гайдлайнам можно найти логичное опровержение.
Проверьте, не решал ли кто-то до вас в этом проекте такую же (или сильно похожую) задачу.
Скорей всего он решал конкретную задачу без рассчета на то, что потом его код будет кто-то переиспользовать. И пытаясь переиспользовать код, вы для разных функциональных кусков вносите общую зависимость, которая потом усложнит поддержку и эволюцию каждого из них. Закопипейстить менее болезненное мероприятие.
Знайте и любите утилиты и API собственного проекта. Особенно, если ему больше полугода. Там могут найтись жемчужины, которые сэкономят вам десятки строк кода.
Там скорей всего не жемчужины, а сплошные перлы. Если чья-то утилита работала в чьем-то коде, совсем не значит, что она также заработает в вашем. Кроме того, название запросто может не соответствовать содержимому.
Ещё знайте и любите популярные библиотеки для вашего языка или платформы
Иногда только из-за одной функции подтягивают кучу зависимостей.
Код заслуживает быть вынесенным в отдельную функцию
То есть, когда была объемная, но линейная функция, отражающая какой-то процесс или алгоритм, теперь она раздраконена и раскидана по всему файлу. Это улучшит читаемость? А еще входные и выходные параметры нужно везде мепить...
Не совсем понятен мотив использования электрона. У вас уже есть одна зависимость в системе — JVM, и наличие зависимости от браузера уже не принципиально. Сделайте Jetty + Vaadin и открывайте при запуске страницу в system default browser. Ваш электрон в минималке займет лишние 100Mb. Если попытаетесь заэмбеддить jre, то это еще плюсом 180мб, а если все скомпилируете AOT, то будет около 250мб. Итого 350мб для простого "хелло ворлд", что может быть и оправдано для девтулзы, но для простого нативного клиента — вряд ли.
Далее, так ли принципиальна зависимость от джавы? Для клиентских технологий есть куча приблуд для джавы: JSweet, GWT, TeaVM, вплоть до полной JVM на JS: CheerpJ.
Ну и по способу деплоймента: зачем бандлить электрон и установщик и почему бы не сделать Chrome Application, распространяемую через Chrome Store?
Отлично. Во многом увидел себя. С тем лишь отличием, что мне все еще нравится моя работа, несмотря на выгорание. К причинам я могу добавить еще:
Частое переключение. Мы все знаем, что переключение контекстов — дорогостоящая операция для процессора, но она на порядки дороже для головного мозга. Когда тебя заставляют часто переключаться между разными проектами, особенно когда в данный момент сконцентрирован на одном, внезапно тебя срочно просят дописать или исправить баг в проекте месячной давности, который уже вытеснен из головного кэша. А потом также трудно вернуться к основному проекту.
Отсутствие вИдения результатов своего труда. Когда ты коммитишь, а сборку делает другой, а установку третий, а поддержку четвертый. Фидбек возвращается тебе исключительно ввиде issues, большая часть из которых не связана напрямую с кодом.
К предыдущему пункту: отсутствие общения с живым клиентом. Работа всегда идет через челопрокси (как Tom Smykovsky из Office Space), либо людей из саппорта, либо вообще встревают левые люди, которые не имеют прямого отношения к проекту.
Распределение поощрений. Когда за твои идеи и твою реализацию клиент благодарит саппорт (деплойнувшего софт) и начальника (отчитавшегося об успехе), а тебе лишь форвардят мейлом поздравление клиента, который вобщем-то особо и не знает о твоем существовании. Демотивирует. Благо в моем случае премию все-таки выписывают.
Перфекционизм. Постоянное желание продемонстрировать себя и свои возможности, и сделать все максимально хорошо. Огромное количество сил тратится на это, причем в порыве перфекционизма человек не контролирует их расход. С другой стороны играет фактор времени и дедлайн — приходится осознанно делать хрень, не получая от этого должного удовлетворения.
Перегруженность навыками. Технологии постоянно меняются. Хочется всегда быть в тренде, попробовать новый фреймворк, технологию, методику. В результате на изучение и освоение тратится гораздо больше сил, чем на саму задачу. Демотивирует постоянное ощущение того, что ты не догоняешь и не успеваешь за технологиями: только освоил одно — уже другое в моде, и не хватает никаких сил изучить все, что хочется. Признак перегруженности навыками — это когда для простой задачи у тебя в голове возникают сразу десятки методов решения, и ты тупо не можешь выбрать между ними: какой фреймворк, тех. средство или архитектуру использовать, etc...
Специфика работы. Девелопмент — это всегда стресс и негатив, привыкните. Здесь жестко бьются о камни ваши мечты об идеальном коде и совершенной системе. Прежде чем что-то заработает, вы столкнетесь с тонной багов разного рода: как ваших, так и не ваших (фичи). Вашу систему будут смаковать совсем другие люди (некие мифические пользователи), а вам будут присылать только багрепорты и жалобы.
Я не знаю ваш юзкейс, поэтому не могу судить о резонности применения ESB. В нашей среде практически все системы общаются через SOAP и Rest в рамках установленных бизнес-процессов. ESB здесь лишняя.
По поводу выбора инструментов: разобраться с Camel-ом не составит труда любому компетентнорму джависту. А вы попробуйте сделать то же самое на каком-нибудь пропиетарном продукте типа IBM Message Broker или Oracle Service Bus. Сначала встанет проблема найти соответствующих специалистов, затем вы ужаснетесь их ценам, и, наконец, разочаруетесь в их профессиональной компетентности. В итоге любое изменение в ESB выходит гораздо дороже и больнее, чем в системах.
Ну это какой-то очень специфический пример. В реальных процессах взаимодействие между системами сводится к двум типам операций: когда одна система должна либо вызвать другую и получить от нее какие-то данные (request-reply), либо оповестить ее о событии (one-way). В теории ESB преподносят как решение следующих задач:
Роутинг. Системы ничего не должны знать об инфраструктуре, вместо этого они имеют single connection point с ESB, которая осущесвляет доставку месседжей до получателя.
Assured delivery. Абстрагирование от транспорта, защита от сбоев сети, остановов систем, перегрузки, etc...
Версионирование и адаптация. Позволяет системам иметь разный релизный цикл. Для каждого получателя ESB может адаптировать формат сообщения и обеспечить совместимость.
Мониторинг.
Однако это в теории. А на практике:
Инфраструктура меняется редко, есть более простые решения service discovery, начиная от DNS и заканчивая Consul-ами. К тому же с современной тенденцией контейнеризации и клаудизации это становится неактуальным. А single connection point усложняет взаимодействие 1-N, когда producer должен отвечать одному из N consumer-ов, который послал запрос. Появляется таблица правил роутинга, и прочая ненужная фигня.
Ребята, которые сидят на ESB, иногда не слыхивали самого термина QoS, и уж тем более какие параметры установлены. Например ситуация, когда клиент уже устал ждать запрос и благополучно отвалился с ошибкой, а ESB все еще пытается задвинуть request в удаленную систему, вызывая тем самым рассинхронизацию общего состояния. О существовании DLQ узнают только, когда она вдруг переполняется.
Иногда необходимо только для интерфейсов 1-N. Но как правило service consumers без посторонней помощи сами адаптируются к изменениям интерфейса producer-ов, а producer-ы зачастую сами версионируют свои интерфейсы, либо поддерживают обратную совместимость. Большинство же корпоративных интерфейсов 1-1, и оба — producer и consumer синхронно эволюционируют в рамках затронувшего изменения. Так что ESB тут пятым колесом.
Серьезно? У вас че-то не работает — ваши проблемы. А эти ребята из ESB всегда с краю. Пока их мордой не ткнешь в косяк. А когда начинают теряться месседжи, так вообще футбол: A: "мы все отправили", B: "мы ничего не получили", ESB: проблемы где-то у вас, мы ничего не знаем.
А вот реальный пример как работает эта ваша ESB в корпоративном секторе. Система TOA должна списывать расходный материал в инвентаре, хранящемся в SAP. Посредник — Oracle Service Bus, через который посылается месседж о расходе. Временами SAP подглючивает, либо валится, и месседж не проходит (их светлость не соблаговолила разобраться с проблемой). ESB оказались не в состоянии обеспечить deferred re-delivery (или попросили за эту фичу круглую сумму — история умалчивает). В итоге дешевле и проще оказалось написать демона, который в конце рабочего дня лезет в TOA и аптейдит неучтеные расходы в SAP.
И вот на том и стоит весь корпоративный сектор: мажорные говнопродукты + куча скрепляющего самопального говна.
Архитектор? Не, не слышали. В лучшем случае вся архитектура — это tutorials + best practices от производителя.
Насчет полезности ESB, лично моя практика показывает, что это не работает даже в компаниях с низким уровнем раздолбайства. По задумке команда ESB должна быть ответственна за все корпоративные интерфейсы: за дизайн, разработку, сопровождение, версионирование. Реально же получается, что системщики каждый раз умоляют их замепить уже задизайненные нужные им интерфейсы или изменить какой-то меппинг, а сами ESB-шники никогда ни о чем не вкурсе, тупо сидят на продукте и постоянно отнекиваются. В итоге ESB превращается в рудиментарную вещь, которая тупо мешает сразу всем.
Блин, как знакомо! Почти то же самое, только в одной крупной испанской транснациональной корпорации. Инструменты разработки — стек пропиетарных говнопродуктов нескольних крупных производителей со всеми вытекающими маразмами: BPM, ESB, MQ, Unix, Spark. Специалистов разработки нет. Организационная структура — перевернутая пирамида (продукт надо задвинуть в несколько стран, соответственно на каждую страну свой менеджер с командой дармоедов и т.д.). Постоянные трения, борьба за влияние и выяснение кто главный. Коммуникаций между командами никаких — каждый ревностно защищает свой огород, чтобы казаться незаменимым. Команда постоянно пухла, но вместо специалистов нанимались новые руководители, которые были даже не в курсе, кто и над чем работал в их команде. Проект переживал постоянные реорганизации, только за мое время сменилось 5 начальников. Специалисты вместо кодинга собирались в комнате и неделями обсуждали концептуальность того или иного решения, рисуя на доске бесконечные ящики и стрелочки.
В итоге проект зашевелился, когда наступил кризис, закончилось бабло и уволили 90% команды.
Из плюсов: платили хорошо, бабла было немеряно, кормили на убой, сортиры мыли несколько раз за день, кофе бесплатный, работа начиналась в 10:30.
Форкаете продукт в отдельную клиентскую ветку. Имплементируете фичи, потом то, что можно переиспользовать, тянете в основную ветку. С клиентом составляете план, где деливери фич и оплата будут производиться поэтапно, с перспективой роста ваших производственных мощностей. Так много продуктов и компаний раскрутилось — прицепившись к одному толстому клиенту.
С другой стороны, клиент, который, увидев ваш самокат собранный на коленках из г-на и палок, требует от вас продать ему такой же, но мотоцикл, скажем так, не совсем адекватен. Дело не в том, что это невозможно, а в том, что тот, кто делает мотоциклы, заделиверит его клиенту гораздо быстрее и дешевле. Но если ему нужен именно ваш самокат и он готов за это платить — ради бога.
Согласно моему опыту, толстый клиент требует не столько новых фич, сколько покрытия всяких очень специфических кейсов. И тут возникает дилемма — с одной стороны хочется заимплементить функционал как можно более generic-ом, модульным и гибким, чтобы потом можно было его переиспользовать, а с другой — не хочется сильно заморачиваться для каждого конкретного кейса, и проще вставить костыль прямо в код системы. И в итоге так или иначе ваш продукт превращается в сервис. Соответственно и экономическая модель должна быть как у сервиса, а не как у продукта.
Если честно, я нифига не понял. Общее впечатление — крупно продешевили на этапе продаж. Потому что в итоге все упирается в деньги — остальное все так или иначе решается. Не хватает фич — наймите больше девелоперов, сделайте специализированный форк продукта, организуйте техподдержку… По ходу автор застрял еще в девяностых и продает коробочную версию своего продукта, поэтому идеальный клиент для него — тот, который молча пришел в магазин, купил и установил на свой ПК.
Хреновых клиентов бывает два типа:
Жмот. Это тот, который изначально не расположен платить за продукт или услуги. Купив базовую версию по огромной выклянченой скидке, он потом вынесет всем мозг, и еще потребует за это деньги. Как правило распознать таких клиентов несложно, и их нужно посылать сразу.
Самодур. Сорит деньгами, но при этом требует танцевать на животе со спущенными штанами. Все силы и деньги будут уходить на реализацию нефункциональных требований, свистелок и перделок, тогда как реально необходимые задачи окажутся непокрытыми. Вскоре проект признают нерентабельным и от него откажутся, а крайним окажетесь вы, ибо "несправились с возложенными надеждами".
Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.
Именно, когда весь функционал — это большое количество небольших независимых напрямую друг от друга задач. А вот например когда вам нужно провести полный редизайн системы для последующего роста, вы задолбаетесь делить задачи и сортировать по их зависимости друг от друга.
Scrum основан на ряде априорных допущений и упрощений, которые в общем случае не верны, и зачастую создает лишь видимость эффективной работы. К сожалению, нет объективных и достаточно надежных показателей, позволяющих оценить эффективность внедрегия scrum.
Очень круто! Действительно Idea очень сильно завязана на Swing. Много было разговоров по поводу Cloud IDE, которая должна будет четко разделять функционал фронтэнда и бэкэнда, но по-моему вся идея заглохла.
А не смотрели в сторону более легких решений на подобие http://creamtec.com/products/ajaxswing/index.html? Это что-то типа RDP на базе Graphics2D и Canvas.
Следующий шаг — обязать всех ходить через прокси провайдера, который будет внаглую подменять сертификаты ssl, а чтобы браузер не ругался, обязать установить в браузере "их" certificate autority.
Все-таки надо различать пользователей, которые пишут библиотеки/фреймворки от тех, кто пишет бизнес логику. Первых очень немного, и они как правило вкурсе всевозможных оптимизаций. Вторых большинство, и они уже используют оптимизированные (или не очень) библиотеки для реализации своих задач.
Поэтому если у вас BigData и вам приходится перелопачивать мегатонны, то скорей всего вы плохо используете данную технологию: там как правило уже есть встроенные оптимизированные средства перелопачивания ввиде Hive, Spark или KSQL. В итоге бизнес работает с уже перелопаченной выжимкой, где особая оптимизация не нужна.
И да, иногда покупка нового сервера обходится дешевле, чем затраты на оптимизацию, проверку и поддержку кода.
Неужели у кого-то реально проект из-за того, что он неправильно пользовал StringBuilder или stream вместо for? В 95% случаев всегда тормозит база данных, причем в половине случаев решение не такое тривиальное, как просто переписать запросы: требуются серьезные архитектурные модификации, использование кешей и т.д. Кроме того, на продакшне ситуация может сильно отличаться от тестового бенча, поэтому всякие профайлеры тут не помогут. Поэтому совет один — используйте лайв мониторинг и фреймворки типа Metrics, пишите понятный код и не сильно забивайте голову всей этой фигней по поводу stream/for, StringBuilder, etc...
Дык, захардкодьте весь дефолтный конфиг значениями прямо в бинах, как я показал выше. А в xml нужно будет прописывать только элементы, значения которых отличаются. JAXB будет создавать объект с дефолтными параметрами, и перезаписывать только поля, указанные в xml. В идеале с пустым xml будет создаваться полный дефолтный конфиг.
Меня всегда интересовал вопрос, как правильно поставить процесс разработки и тестирования в приложении с OSGi-контейнером? Модуль после каждого изменения приходится запаковывать и передеплоивать. Кроме того нет возможности стартануть контейнер из workspace с подцепленным classpath модуля, соответственно невозможно будет дебажить в IDE, или делать hot replace. Даже в JEE есть такие средства как Arquillian, OpenEJB, Microprofile, которые сильно упрощают разработку...
Не совсем понял, что вы имеете ввиду под "наследованием" конфигов. Если это наследование бинов, то у JAXB с этим проблем нет. А если дефолтные значения для полей, то их можно указывать прямо при описании самих полей:
Да полно. Вот очень неплохой вариант: http://owner.aeonbits.org/.
Для себя я уже давно решил проблему конфигов: использую стандартный JAXB. Структура описывается прямо в бинах при помощи парочки аннотаций. Все сериализуется в XML. Maven автоматически генерит XSD, который понимает IDE и позволяет делать autocomplete при редактировании конфига.
«Цифровая экономика Российской Федерации» — это все правильно и хорошо. Однако возникает вопрос об экономической целесообразности данной программы. Выражаясь простым языком, на программу будут потрачены серьезные государственные средства, но нигде даже не оговариваются способы возврата инвестиций. Из программы понятно, что:
Опять поиски серебряной пули. Не существует универсального метода написания кода и разбивки на части. Всегда любым гайдлайнам можно найти логичное опровержение.
Скорей всего он решал конкретную задачу без рассчета на то, что потом его код будет кто-то переиспользовать. И пытаясь переиспользовать код, вы для разных функциональных кусков вносите общую зависимость, которая потом усложнит поддержку и эволюцию каждого из них. Закопипейстить менее болезненное мероприятие.
Там скорей всего не жемчужины, а сплошные перлы. Если чья-то утилита работала в чьем-то коде, совсем не значит, что она также заработает в вашем. Кроме того, название запросто может не соответствовать содержимому.
Иногда только из-за одной функции подтягивают кучу зависимостей.
То есть, когда была объемная, но линейная функция, отражающая какой-то процесс или алгоритм, теперь она раздраконена и раскидана по всему файлу. Это улучшит читаемость? А еще входные и выходные параметры нужно везде мепить...
Они все испортят ©! Сейчас мы переживаем фактически начало заката Java. Экосистема не будет поспевать за новым релизным циклом, а Java движется в сторону постоянного ломания совместимости. С Java 8 прокатило, поскольку все давно ждали лямбды и стримы. Но в последних версиях количество вещей реально полезных для финального пользователя, остается минимальным. В итоге экосистема форкнется на две: с одной стороны будет небольшая группа early adopters, а с другой — огромный "легаси", который не будет спешить никуда мигрировать. Резко упадет количество решений, совместимых с новыми версиями Java, и общий интерес к Java платформе потихоньку начнет падать в угоду альтернативам. По моим оценкам Java 8 задержится еще минимум лет на 5, а потом внезапно появится что-то еще...
Не совсем понятен мотив использования электрона. У вас уже есть одна зависимость в системе — JVM, и наличие зависимости от браузера уже не принципиально. Сделайте Jetty + Vaadin и открывайте при запуске страницу в system default browser. Ваш электрон в минималке займет лишние 100Mb. Если попытаетесь заэмбеддить jre, то это еще плюсом 180мб, а если все скомпилируете AOT, то будет около 250мб. Итого 350мб для простого "хелло ворлд", что может быть и оправдано для девтулзы, но для простого нативного клиента — вряд ли.
Далее, так ли принципиальна зависимость от джавы? Для клиентских технологий есть куча приблуд для джавы: JSweet, GWT, TeaVM, вплоть до полной JVM на JS: CheerpJ.
Ну и по способу деплоймента: зачем бандлить электрон и установщик и почему бы не сделать Chrome Application, распространяемую через Chrome Store?
Отлично. Во многом увидел себя. С тем лишь отличием, что мне все еще нравится моя работа, несмотря на выгорание. К причинам я могу добавить еще:
Я не знаю ваш юзкейс, поэтому не могу судить о резонности применения ESB. В нашей среде практически все системы общаются через SOAP и Rest в рамках установленных бизнес-процессов. ESB здесь лишняя.
По поводу выбора инструментов: разобраться с Camel-ом не составит труда любому компетентнорму джависту. А вы попробуйте сделать то же самое на каком-нибудь пропиетарном продукте типа IBM Message Broker или Oracle Service Bus. Сначала встанет проблема найти соответствующих специалистов, затем вы ужаснетесь их ценам, и, наконец, разочаруетесь в их профессиональной компетентности. В итоге любое изменение в ESB выходит гораздо дороже и больнее, чем в системах.
Ну это какой-то очень специфический пример. В реальных процессах взаимодействие между системами сводится к двум типам операций: когда одна система должна либо вызвать другую и получить от нее какие-то данные (request-reply), либо оповестить ее о событии (one-way). В теории ESB преподносят как решение следующих задач:
Однако это в теории. А на практике:
А вот реальный пример как работает эта ваша ESB в корпоративном секторе. Система TOA должна списывать расходный материал в инвентаре, хранящемся в SAP. Посредник — Oracle Service Bus, через который посылается месседж о расходе. Временами SAP подглючивает, либо валится, и месседж не проходит (их светлость не соблаговолила разобраться с проблемой). ESB оказались не в состоянии обеспечить deferred re-delivery (или попросили за эту фичу круглую сумму — история умалчивает). В итоге дешевле и проще оказалось написать демона, который в конце рабочего дня лезет в TOA и аптейдит неучтеные расходы в SAP.
И вот на том и стоит весь корпоративный сектор: мажорные говнопродукты + куча скрепляющего самопального говна.
Архитектор? Не, не слышали. В лучшем случае вся архитектура — это tutorials + best practices от производителя.
Насчет полезности ESB, лично моя практика показывает, что это не работает даже в компаниях с низким уровнем раздолбайства. По задумке команда ESB должна быть ответственна за все корпоративные интерфейсы: за дизайн, разработку, сопровождение, версионирование. Реально же получается, что системщики каждый раз умоляют их замепить уже задизайненные нужные им интерфейсы или изменить какой-то меппинг, а сами ESB-шники никогда ни о чем не вкурсе, тупо сидят на продукте и постоянно отнекиваются. В итоге ESB превращается в рудиментарную вещь, которая тупо мешает сразу всем.
И да, продукты дерьмо!
Блин, как знакомо! Почти то же самое, только в одной крупной испанской транснациональной корпорации. Инструменты разработки — стек пропиетарных говнопродуктов нескольних крупных производителей со всеми вытекающими маразмами: BPM, ESB, MQ, Unix, Spark. Специалистов разработки нет. Организационная структура — перевернутая пирамида (продукт надо задвинуть в несколько стран, соответственно на каждую страну свой менеджер с командой дармоедов и т.д.). Постоянные трения, борьба за влияние и выяснение кто главный. Коммуникаций между командами никаких — каждый ревностно защищает свой огород, чтобы казаться незаменимым. Команда постоянно пухла, но вместо специалистов нанимались новые руководители, которые были даже не в курсе, кто и над чем работал в их команде. Проект переживал постоянные реорганизации, только за мое время сменилось 5 начальников. Специалисты вместо кодинга собирались в комнате и неделями обсуждали концептуальность того или иного решения, рисуя на доске бесконечные ящики и стрелочки.
В итоге проект зашевелился, когда наступил кризис, закончилось бабло и уволили 90% команды.
Из плюсов: платили хорошо, бабла было немеряно, кормили на убой, сортиры мыли несколько раз за день, кофе бесплатный, работа начиналась в 10:30.
Форкаете продукт в отдельную клиентскую ветку. Имплементируете фичи, потом то, что можно переиспользовать, тянете в основную ветку. С клиентом составляете план, где деливери фич и оплата будут производиться поэтапно, с перспективой роста ваших производственных мощностей. Так много продуктов и компаний раскрутилось — прицепившись к одному толстому клиенту.
С другой стороны, клиент, который, увидев ваш самокат собранный на коленках из г-на и палок, требует от вас продать ему такой же, но мотоцикл, скажем так, не совсем адекватен. Дело не в том, что это невозможно, а в том, что тот, кто делает мотоциклы, заделиверит его клиенту гораздо быстрее и дешевле. Но если ему нужен именно ваш самокат и он готов за это платить — ради бога.
Согласно моему опыту, толстый клиент требует не столько новых фич, сколько покрытия всяких очень специфических кейсов. И тут возникает дилемма — с одной стороны хочется заимплементить функционал как можно более generic-ом, модульным и гибким, чтобы потом можно было его переиспользовать, а с другой — не хочется сильно заморачиваться для каждого конкретного кейса, и проще вставить костыль прямо в код системы. И в итоге так или иначе ваш продукт превращается в сервис. Соответственно и экономическая модель должна быть как у сервиса, а не как у продукта.
Если честно, я нифига не понял. Общее впечатление — крупно продешевили на этапе продаж. Потому что в итоге все упирается в деньги — остальное все так или иначе решается. Не хватает фич — наймите больше девелоперов, сделайте специализированный форк продукта, организуйте техподдержку… По ходу автор застрял еще в девяностых и продает коробочную версию своего продукта, поэтому идеальный клиент для него — тот, который молча пришел в магазин, купил и установил на свой ПК.
Хреновых клиентов бывает два типа:
Именно, когда весь функционал — это большое количество небольших независимых напрямую друг от друга задач. А вот например когда вам нужно провести полный редизайн системы для последующего роста, вы задолбаетесь делить задачи и сортировать по их зависимости друг от друга.
Scrum основан на ряде априорных допущений и упрощений, которые в общем случае не верны, и зачастую создает лишь видимость эффективной работы. К сожалению, нет объективных и достаточно надежных показателей, позволяющих оценить эффективность внедрегия scrum.