"Подумаешь… Я еще и вышивать могу… И на машинке… тоже..." ;)
Это все очень хорошо, поздравляю. Однако постоянно растущее количество технологий и областей применения так или иначе требует более узкой специализации. Если вы во всех достигли уровня "бог", то снимаю шляпу — тут не о чем разговаривать.
Мне лично попадались за всю практику "специалисты широкого профиля" или "просто программисты" — человеки, которые в 201x на Java итерируют списки при помощи for (int i = 0; i < list.size(); i++) list.get(i). Им впринципе все-равно на чем писать — все языки похожи, а stackoverflow и google всегда под рукой. Требуемую задачу они решают методом копипейста или точечного патчинга чужого кода. Их обычно ставят в проект, чтобы они были вкурсе, и чтобы потом их можно было оставить на саппорте, когда основной девелопмент уже завершен.
Но тем не менее так или иначе на рынке труда все-равно будет необходимо позиционировать себя в какой-то одной области, либо паре смежных областей. Но иногда в некоторых стартапах действительно бывает необходимо хороший специалист, компетентный сразу во многих областях.
Степень, достаточная для того, чтобы быть полезным потенциальному работодателю для решения поставленных бизнес-задач.
Сама строчка о языках ничего не говорит. В тайтле вы должны четко дать понять кто вы, и чем конкретно вы можете быть полезны работодателю. Стоит акцентировать внимание не столько на языках, сколько целевых на технологиях, платформах или бизнес-областях, в которых вы работаете. Никому не нужен просто assembler, зато требуется запрограммировать конкретный микроконтроллер или написать драйвер ядра Linux. Вместо bash-а будут искать администрирование Unix/Linux. Что вы делаете на C/C++: программирование под Win32, под Linux, геймдев или еще что? JavaScript тоже ни о чем. Вы фронтендер? Разрабатываете под ключ вебприложения?
Не бойтесь выбрасывать мусор из резюме — больше не лучше. Вы будете реже выходить в поиске, зато более целенаправленно.
P.S. Технологии и языки хорошо указывать в своем портфолио, когда они связаны с конкретными проектами. Так у HR-а создается представление о вашем профиле.
Вот с этим на все 200% не согласен. Это никогда не работает, сколько я видел систем. У всех производителей BPMS есть эта красивая идея сотрудничества: типа бизнес-бог определяет требования и расставляет на схеме мышкой ящички и стрелочки, а черти-программеры в этой же схеме уже подтягивают интерфейсы, делают меппинг данных, формочки, etc… Иногда для этого используется два разных набора тулзов, но идея, чтобы у них обоих отображался один и тот же процесс. Так вот, сколько я BPM систем ни видел, это нигде не работает. Всегда есть одна версия процесса, написанная аналистом и используемая для исключительно для документации, и есть другая, "рабочая" версия, которая порой абсолютно не похожа на изначальную, и которая написана программерами в соответствие с изначальными требованиями. И проблемы здесь начинаются не с кривых рук или глючного софта, а с порочности самой идеи: когда при реализации вылезают определенные детали, то бизнес-бог не особо слушает рекомендации чертей-программеров и черта-с-два изменит что-то на своей схеме — он птица высокого полета и не должен думать о деталях. А дьявол всегда кроется в деталях.
Работал с несколькими открытыми системами( как пример Camunda ). Доступ к базе в открытых системах есть, что очевидно.
Есть задача — пропатчить бизнес-логику, не завершая запущенные процессы. Юзал Activiti и jBPM — там есть описание структуры таблиц, и можно разобраться с состоянием процессов, на то он и OpenSource. Но точно также крайне сложно сделать корректный патч, который не порушит запущенные процессы (хотя зависит от характера изменений), и также приходится следить за всеми дельтами. И тут BPMS никак не поможет — они предлагают задеплоить новую версию для новых процессов, пока старые завершатся по-старому. А в пропиетарных BPMS вообще нет способа патчинга (все состояние закрыто семью печатями), а в некоторых и версионирование криво работает. Так что за мою деятельность у меня столько юзкейсов скопилось, которые ни одна BPMS не решает, а наоборот, мешает, что потребуется целая статья (начиная от "просто добавить поле").
Если речь идет не о долях секунды, то это не реалтайм
Если следовать определению, это именно реалтайм — процессы, синхронизированные со временем и, как частный случай, имеющие гарантированное время отклика.
У любого специалиста есть какой-то определенный инструментарий — то, чем он хорошо владеет на данный момент, и что напрямую связано с его работой. Плюс за годы накопился определенный багаж — то, с чем он когда-то работал раньше, но что уже подзабылось или вышло из тренда. Затем у каждого имеются интересы в различных областях — то, что активно хочется изучить и освоить.
В резюме важно, чтобы это все смотрелось органично и не вызывало дополнительных вопросов. Вот добавьте в свое резюме рядом с C/C++ строчку JS/Node, и сразу появится куча вопросов. Вы втихаря пилите свой JS-движок? Участвуете в разработке Node? Или просто ищите вакансию, которая вам поможет в освоении фронтенда? А вот с резюме фронтэндера таких вопросов не возникнет.
Есть люди, у которых баланс нарушен от освоения в сторону лишь изучения нового материала. В этом случае, даже имея официальный сертификат, все их знания будут поверхностны, ибо для освоения технологии требуется более глубокая и объемная работа, нежели написание "Hello World"-ов. А для этого требуется время, которого сверхурочно нигде не возьмешь. Поэтому когда в резюме стоит строчка типа: С/C++, Java, Python, C#, JS, PHP, Go, Rust, то скорей всего он не владеет в достаточной степени ни одним из этих языков.
Более того, все понятые и запомненные тонкости частенько забываются
А это огромный плюс нашей памяти — делать автоматическую очистку мусора. Основной скилл для HR в этом случае не само знание, а то, что чел однажды смог хорошо разобраться с данной технологией.
Мне кажется в нашей профессии очень сильно демотивирует постоянно растущее количество технологий, которое к тому же полностью обновляется раз в два года. Всего не выучишь, за всем не уследишь, а ощущение того, что ты не на гребне волны или есть что-то чего-то не знаешь, сбивает самооценку. Тем более, что вероятно вам никогда не приведется пощупать очередной хайповый тренд, по которому следующие два года будут делать запросы HR-ы. Кроме того немаловажную роль здесь играют всевозможноые расхайпованные на конференциях и соцсетях "гуру", таким образом задающие планку. Наш специалист, сидя в зале, пытается оценить себя по навязанной шкале и то, на что он может претендовать в сравнении с выступающим.
А теперь разложим все "по понятиям".
90% "новых" хайповых технологий на деле является дерьмом, потому как:
это либо топтание на месте: а давайте все вместе будем дружно использовать новую парадигму/язык/платформу, потому что это сейчас будет модно.
либо переизобретение велосипеда на другом стеке — происходит периодически каждые 5-10 лет, когда подрастает новое поколение, использующее новые средства разработки. Все эти "новые" идеи уже были когда-то реализованы раньше, либо заимствованы из другого стека. Причем, как правило, "раньше было лучше".
иногда имеет очень специфическую область применения, с которой вы вряд ли столкнетесь, как например блокчейн или бигдата, но тем не менее расхайповано как средство первой необходимости
выглядят привлекательно только на презентации. Нормальная технология содержит не столько абстрактную идею, сколько реальный опыт ее применения. При внедрении же новых технологий всегда внезапно вылазит стопицот побочных проблем разного характера.
есть попытка продать собственный продукт или поддержку.
выйдут из моды через 2 года или будут заменены другими.
Гуру, выступающие на конференциях или публичных площадках:
обычно представляют труд большого числа людей "за сценой"
как правило являются достаточно узкими специалистами в своей области
многие из них уже давно не пишут код (когда активность в твиттере становится выше, чем активность в репозитории собственной компании)
редко являются финальными пользователями своих изобретений
выступают в роли шоуменов для раскрутки собственной компании и продуктов
так или иначе получают за это деньги
Вы реально классный специалист, если:
можете с нуля без посторонней помощи написать бизнес-приложение
владеете определенным стеком технологий для реализации данной задачи
способны к самостоятельному обучению
стараетесь быть "в теме": интересуетесь последними веяниями и разработками
обладаете здравым смыслом и критикой
несмотря ни на что вам нравится ваша работа, и вы в ней не только из-за денег
Вы должны осознавать:
большинство HR-ов некомпетентно в IT (а некоторые и в HR)
универсальный специалист, подобный швейцарскому ножу — это хреновый специалист, не делающий нормально ни одну из функций
есть люди, которые лучше умеют себя продавать. Это не делает их лучше как специалистов.
наша работа должа приносить удовлетворение
если вы не прошли собеседование, то возможно это не вы не подходите компании, а компания не подходит вам
Вопрос такой: а если патчуемый код уже заинструменчен каким-нибудь фреймворком в рантайме? Будет ли повторно вызываться инструментация фреймворка или нет?
Другой вопрос: а как вы тестируете сам процесс патчинга? HCR очень деликатная и ограниченная штука, и успешно пропатчить код может лишь в некоторых случаях. И вот у вас зафейлился патч на продакше. Что делать дальше?
Вообще, я нахожу использование такого подхода более чем странным особенно для Одноклассников. Как я себе представляю подобные системы, перезагрузка одного сервиса никак не должна влиять на общую работу: микросервисы, распределенность и все такое… Если же система монолитная или ее рестарт занимает значительное время, то можно попытаться разделить всю логику на контексты внутри приложения при помощи класслоадеров и рестартать их вбелую по мере необходимости. Или например использовать OSGi, где все это уже реализовано из коробки ввиде модулей. Но патчить на продакшне через интерфейс, предназначенный для дебага — это странное решение.
Я говорю о ситуации валидного кода, позволяющего реализовать не валидный с точки зрения бизнес процесс
Это совершенно не зависит от способа реализации. В любой системе есть возможность написать невалидный рабочий код. И если нет человека, который контролирует всю бизнес логику, то о чем мы говорим — логика сама себя не напишет.
А потом в конечно автомате появляются проверки условий
Все это уже доступно из коробки, например в том же Spring. Поставил одну аннотацию — получил транзакцию. Поставил пару других — вот и rest заработал. Вся эта требуха не относится напрямую к задаче BPM, или бизнес логике. И фреймворков различных для этого написано огромное количество, и кроме того любая BPMS всегда стоит поверх какой-то платформы/фреймворка: SCA, JavaEE, Spring, etc… BPM — это сугубо задача асинхронного выполнения логики с возможностью сохранения/восстановления состояния. И есть также десятки способов реализовать это. Акторы, корутины, execution graphs, etc...
Есть. Хоть через базу, хоть через rest, хоть через gui.
Мы о какой-то конкретной системе говорим? Во всех пропиетарных системах, что я видел, состояние процесса сохраняется во внутренних таблицах, к коим не предусматривается сторонний доступ. Есть консистентный, но очень ограниченный API, который иногда позволяет манипулировать переменными процесса извне, но не контролировать само выполнение процесса.
Это точно бизнес процессы, а не технологические?
Именно бизнес процессы, синхронизированные со временем. У стороннего сервиса есть техническое окно в котором можно оперировать. Есть планировщик, который позволяет выставлять процессам приоритет для доступа к сервису, согласно критериям. Если процесс не удается завершить по истечении окна, его нужно перепланировать на следующий день. Кроме того там много логики, касающейся SLA как с нашей стороны, так и со стороны сервисов: ответ должен быть гарантирован втечение установленного времени — если нет, то налагаются штрафы. Ну и естественно по приближении дедлайна система должна выдавать всевозможные алармы. Вобщем, на BPMS логику реализовать не осилили — пришлось писать свой модуль.
Плюс, конечно же, очень желательно предусмотреть случаи, когда данные начинают рассогласовываться по вине той или другой стороны:
Ну вот. И теперь смотрите, насколько усложнилась задача для синхронизации одной лишь сущности. Если у вас есть несколько сущностей, или еще хуже, некая реляционная модель, связывающая их всех, то сложность процесса синхронизации увеличивается на порядки. Например, приходится производить многопроходную актуализацию, зачастую приходится отключать всяческие constraints (которые потом обратно не всегда включаются). А в некоторых случаях задача корректной синхронизации вообще неразрешима.
А паттерн «shared database», на мой взгляд, — это такая фальшивая децентрализация
Тем не менее только он гарантирует постоянную консистентность всех данных. Другое дело, что не во всех кейсах это так необходимо.
Если коробка или коробка с доработками от вендора дешевле 10млн.рублей, то заниматься своей разработкой бессмысленно.
Совершенно верно. Это если мы говорим о продукте, который покрывает конкретную, хорошо определенную и достаточно типовую область бизнес логики. И тем не менее даже здесь встают проблемы, когда сценарии клиента не соответствуют заложенным в продукте, а реализовать эти сценарии в ограниченном продукте не представляется возможным, либо связано с огромными расходами ввиду недостаточной гибкости продукта. Тут начинают появляться всякого рода велосипеды, приставленные сбоку. Другой проблемой всегда является интеграция с экосистемой клиента: здесь уже появляется слово заумное слово "архитектура", все вышеперечисленные автором проблемы и еще больше самопальных велосипедов.
Я же имею ввиду именно платформы-конструкторы как какой-нибудь Roga&Kopyta BPM SOA Suite, которые вообще не покрывают ни один из бизнес кейсов, но позиционируют себя как платформу для разработки и интеграции любых бизнес сценариев. Сомнительное утверждение, что при помощи подобного самолета можно дешевле и быстрее реализовать бизнес логику, нежели в голом коде. Тем более что от самолета там только красивая панель управления — все остальное также приходится педалить. Какие конкретно
значительно усложнение кода отвечающего за бизнес логику и повышение его связности
Это все абстрактно и надумано. Конечный автомат с персистенцией в базу данных сможет реализовать любой джун. Более того, когда логика процесса изменится, всегда есть возможность контролировать состояние уже запущенных процессов, тогда как в BPMS напрямую к состоянию процесса доступа нет (проблема версионирования).
За все время работы с BPMS я не видел ни одного реально сложного бизнес-процесса. Вся сложность возникала из-за ограниченности аналиста и неумения разделить на функциональные блоки, а также потому, что в BPMN-нотации фактически присутствует "оператор goto", быстро превращающий всю схему в кашу. Там же, где сценарий требовал действительно нетривиальных вещей, таких как синхронизация со временем (realtime), раннее завершение процесса, синхронизацию процессов (race condition), каскадное завершение… — все то, что быстро реализуется в коде, но BPMS не предлагал абсолютно никаких средств, а провайдер предложил купить дополнительный продукт (ESB), который реализует эти самые "Enterprise Integration Patterns".
Декларативное описание, да еще не type-safe, да еще по имени класса/метода с сигнатурой и с wildcards… Прям как новая серия игр "Что? Где? Когда?". Тут простой рефакторинг все сразу поломает.
И главное, для чего? Есть же Proxy.newProxyInstance(), ByteBuddy и BeanPostProcessor для детерминированного инжекта.
А проблема в том, что в одной базе содержатся все марки автомобилей, которую допустим поддерживает головной офис, а в базе филиала Мухосранска локально содержатся все ремонты. Внезапно в головном офисе обнаруживается, что одна и та же модель в базе продублирована как "ВАЗ-2107" и, скажем, "ТАЗ-2107". Везде для карточки клиента использовали первый вариант, и только в Мухосранске сделали второй. Головной офис решил по-тихому расстаться с ТАЗов в модельном ряду и грохнул запись. В итоге ночью тихонько зафейлился скрипт апдейта базы Мухосранского отделения, но этого никто не заметил. Заметили через три месяца, когда система головного офиса не захотела принимать отчет с неизвестной моделью.
А вот реальная история: система сбора информации с сетки (Network Reconciliation). Ночью синхронизировались с GIS для получения новых станций и апаратов. Затем поступали данные от EMS со всеми текущими параметрами станций. В один прекрасный день образовалось несколько гигабайт зафейлившихся логов. Причина проста: GIS и наша система внезамно перешли на зимнее время, тогда как EMS всегда стоят по UTC, и в итоге начинали лить данные со станций раньше, чем мы синхронизировались с GIS, чтобы получить новый список станций. И это еще не затрагивая самой логики data reconcilliation.
Так что синхронизация баз данных — это ужасно. Тут нет универсальных решений, все что можно придумать — все плохо.
А так ли нужен монстр? Практически всегда бизнес логика достаточно простая, а процессы по большей части линейны, потому как клиент редко успешно оперирует сложными моделями. Имеет ли смысл притягивать за уши BPMS там, систему собрать из стандартных компонентов, коих в экосистеме полно — слава богу не в пустыне живем, и всю логику быстро и без напрягов наклепать вручную.
Кроме того, BPMN — это всего лишь стандарт, для того, чтобы он завертелся, необходима какая-никакакя платформа, содержащая в себе визуальные средства разработки, отладки, мониторинга, компоненты интеграции с внешними системами, компоненты работы с моделью данных, мепперы, бизнес-правила, языки сценариев, API для работы сценариев, средства разработки пользовательских интерфейсов (формочек), система управления пользователями, пользовательский портал, etc, etc… Какой-нибудь SOA Suite. Более-менее рабочий продукт, содержащий все вышеперечисленное, будет обязательно пропиетарным. И разработка под него станет ни чем не выгоднее, чем без оного. Это такой красивый швейцарский нож: вроде бы все есть, все как бы можно сделать, но чего не коснись — все неудобно и плохо: ни хлеб нормально не порезать, ни ногти постричь, ни винт открутить, ни вино откупорить.
Это мечта любого заказчика — ты мне дай такой внятный конструктор, на котором я бы смог в любой момент поменять параметр, подправить мышкой бизнес-логику — и все без всяких этих ваших джав, девопсов и прочей фигни. Реально же получается, что заказчику под видом архитектуры задвигают кучу всякого пропиетарного и дорогого барахла типа BPMN, потом он судорожно ищет дорогого специалиста, кто бы мог это все поднять дело и запустить. А затем, не осилив BPMN и Rules Engine, жестко подседает на провайдера, который не стесняется заламывать цены, ибо на рынке всего полтора специалиста по данной системе. И это еще самый оптимистичный сценарий.
И, да, хорошие программисты идеально разбираются в предметной области, зачастую лучше, чем сам заказчик. Понимают специфику работы, нужды заказчика, и сами предлагают оптимальные решения для бизнеса. И да, заменить такого программиста сложно, и это нормально — потеря квалифицированных кадров в любой отрасли негативно отражается на производстве.
Ну вот по поводу общей базы данных: когда каждая система имеет свою копию, относящуюся к одной бизнес сущности, возникает вопрос синхронизации данных и кто является изначальным владельцем. Многие запускают ночные процессы синхронизаций, которые наутро выдают огромные портянки неконсистентных данных (это в лучшем случае), некоторые пробуют онлайн синхронизацию. Но в большинстве случаев никто не заморачивается и просто дают dblink к своей базе — типа сами ищите там все, что вам нужно.
Совершенно верно. У них нет нормальных вещей. Если лет 10 назад в H&M можно было дешево и нормально одеться, то сейчас там висит какой-то улично-молодежный треш для хипстеров, роллеров, мэтросексуалов и прочих неформалов. Причем тенденция затронула не только H&M, но и другие марки: Zara, C&A, Springfield… Извечная боль — найти на мой рост нормальные штаны Straight адекватной длины и рубашку с длинными рукавами.
P.S. AI, проанализировав данные со всех продаж, и подумав какое-то время, выдал неожиданное решение: "может быть вам пора бы уже начать шить нормальную одежду?"
Причина того, что нет более-менее нормального стандартизованного стека технологий разработки. Spring я привел лишь в качестве примера, я сам его недолюбливаю. Однако он интегрируется практически со всеми технологиями, предлагает простой уровень абстракций для управления, и прямо из коробки годен практически для любого проекта. Сегодня пишут на спринге, и завтра тоже будут писать на нем.
Во фронтэнде же не существует более-менее универсального стека разработки. Сегодня есть 50 технологий, хреново интегрирующихся между собой, завтра их будет 150. Вчера был ангуляр, сегодня реакт, завтра какой-нибудь Vue.js или еще 10 других. Вы никогда не поспеете за всем этим. К тому же ваше рабочее время будет тратиться на изучение всего этого дерьма, вместо того, чтобы решать поставленные задачи. Вот я и говорил выше, что согласно моей практике, за последние 10 лет фронтэнд разработка не стала ни быстрей, ни качественней, ни дешевле, тогда как задачи практически не изменились.
Ой ли? На фронтенд даже не постеснялись притащить целый браузер ввиде электрона ради поделки с парой кнопочек. Вот недавняя статья на этот счет. Веб приложения постоянно пухнут, нещадно жрут память и тормозят, при всем том, что их функциональность особо сильно не меняется. И это как бы никого не волнует. Никто не стесняется ради красивой кнопочки подключать сразу всю библиотеку, или ради пары иконок тащить весь фонт.
Так что причина не в этом, а в том, что это вся экосистема JS — это куча мелких говноподелок, склепанных школьниками на коленках. А все, более-менее серьезное в JS было сделано крупными компаниями для внутреннего использования и щедро подарено в оперсорс.
Вы какие-то фантастические аргументы привели ей-богу! Основной аргумент — если ты даже не представляешь что такое блокчейн, и для чего он нужен, то с вероятностью 99% тебе он не нужен совсем. Как правило блокчейн требуют, потому что это модно, и всем хочется соответствовать тренду. Это слово-паразит, которое нужно выжигать каленым железом, что даже боялись заикнуться о нем! 10 лет назад, я помню, таким паразитом был "cloud". Потом Agile… Гипермемы какие-то! Область применения блокчейна очень ограничена, в 100 или 1000 раз меньше, чем об этом говорят. И кстати, убедился на собственном опыте, больше всех говорят о блокчейне те, кто меньше всего представляет, что это такое и с чем его едят.
Это все очень хорошо, но реализация сего злодейского плана потребует на порядки больше затрат, нежели ожидаемая выгода, затрагивает большое количество сфер человеческой деятельности, не связанных с медиаконтентом, идет вразрез с основами прав и свобод человека, а по долгосрочности и рискам не сопоставим ни с одним проектом человечества.
А вот что реально будет и уже происходит — это глобальное удешевление контента и его агрегация в пакеты при помощи глобальных сервисов доставки. За небольшую абонентскую плату ты получаешь огромное количество легального мяса, доступного везде и всегда при помощи всего одного клика. Идея в том, чтобы оплата сама по себе напрягала меньше, чем вся эта возня с пиратскими штучками. Только так можно победить пиратство.
Хорошо помню "Бомжика" на Спектруме. После статьи нагрянула какая-то восьмибитная ностальгия 90-х, когда все было теплым и ламповым. Вот самый ламповый онлайн эмулятор Спектрума: http://torinak.com/qaop
"Подумаешь… Я еще и вышивать могу… И на машинке… тоже..." ;)
Это все очень хорошо, поздравляю. Однако постоянно растущее количество технологий и областей применения так или иначе требует более узкой специализации. Если вы во всех достигли уровня "бог", то снимаю шляпу — тут не о чем разговаривать.
Мне лично попадались за всю практику "специалисты широкого профиля" или "просто программисты" — человеки, которые в 201x на Java итерируют списки при помощи for (int i = 0; i < list.size(); i++) list.get(i). Им впринципе все-равно на чем писать — все языки похожи, а stackoverflow и google всегда под рукой. Требуемую задачу они решают методом копипейста или точечного патчинга чужого кода. Их обычно ставят в проект, чтобы они были вкурсе, и чтобы потом их можно было оставить на саппорте, когда основной девелопмент уже завершен.
Но тем не менее так или иначе на рынке труда все-равно будет необходимо позиционировать себя в какой-то одной области, либо паре смежных областей. Но иногда в некоторых стартапах действительно бывает необходимо хороший специалист, компетентный сразу во многих областях.
Степень, достаточная для того, чтобы быть полезным потенциальному работодателю для решения поставленных бизнес-задач.
Сама строчка о языках ничего не говорит. В тайтле вы должны четко дать понять кто вы, и чем конкретно вы можете быть полезны работодателю. Стоит акцентировать внимание не столько на языках, сколько целевых на технологиях, платформах или бизнес-областях, в которых вы работаете. Никому не нужен просто assembler, зато требуется запрограммировать конкретный микроконтроллер или написать драйвер ядра Linux. Вместо bash-а будут искать администрирование Unix/Linux. Что вы делаете на C/C++: программирование под Win32, под Linux, геймдев или еще что? JavaScript тоже ни о чем. Вы фронтендер? Разрабатываете под ключ вебприложения?
Не бойтесь выбрасывать мусор из резюме — больше не лучше. Вы будете реже выходить в поиске, зато более целенаправленно.
P.S. Технологии и языки хорошо указывать в своем портфолио, когда они связаны с конкретными проектами. Так у HR-а создается представление о вашем профиле.
Вот с этим на все 200% не согласен. Это никогда не работает, сколько я видел систем. У всех производителей BPMS есть эта красивая идея сотрудничества: типа бизнес-бог определяет требования и расставляет на схеме мышкой ящички и стрелочки, а черти-программеры в этой же схеме уже подтягивают интерфейсы, делают меппинг данных, формочки, etc… Иногда для этого используется два разных набора тулзов, но идея, чтобы у них обоих отображался один и тот же процесс. Так вот, сколько я BPM систем ни видел, это нигде не работает. Всегда есть одна версия процесса, написанная аналистом и используемая для исключительно для документации, и есть другая, "рабочая" версия, которая порой абсолютно не похожа на изначальную, и которая написана программерами в соответствие с изначальными требованиями. И проблемы здесь начинаются не с кривых рук или глючного софта, а с порочности самой идеи: когда при реализации вылезают определенные детали, то бизнес-бог не особо слушает рекомендации чертей-программеров и черта-с-два изменит что-то на своей схеме — он птица высокого полета и не должен думать о деталях. А дьявол всегда кроется в деталях.
Есть задача — пропатчить бизнес-логику, не завершая запущенные процессы. Юзал Activiti и jBPM — там есть описание структуры таблиц, и можно разобраться с состоянием процессов, на то он и OpenSource. Но точно также крайне сложно сделать корректный патч, который не порушит запущенные процессы (хотя зависит от характера изменений), и также приходится следить за всеми дельтами. И тут BPMS никак не поможет — они предлагают задеплоить новую версию для новых процессов, пока старые завершатся по-старому. А в пропиетарных BPMS вообще нет способа патчинга (все состояние закрыто семью печатями), а в некоторых и версионирование криво работает. Так что за мою деятельность у меня столько юзкейсов скопилось, которые ни одна BPMS не решает, а наоборот, мешает, что потребуется целая статья (начиная от "просто добавить поле").
Если следовать определению, это именно реалтайм — процессы, синхронизированные со временем и, как частный случай, имеющие гарантированное время отклика.
У любого специалиста есть какой-то определенный инструментарий — то, чем он хорошо владеет на данный момент, и что напрямую связано с его работой. Плюс за годы накопился определенный багаж — то, с чем он когда-то работал раньше, но что уже подзабылось или вышло из тренда. Затем у каждого имеются интересы в различных областях — то, что активно хочется изучить и освоить.
В резюме важно, чтобы это все смотрелось органично и не вызывало дополнительных вопросов. Вот добавьте в свое резюме рядом с C/C++ строчку JS/Node, и сразу появится куча вопросов. Вы втихаря пилите свой JS-движок? Участвуете в разработке Node? Или просто ищите вакансию, которая вам поможет в освоении фронтенда? А вот с резюме фронтэндера таких вопросов не возникнет.
Есть люди, у которых баланс нарушен от освоения в сторону лишь изучения нового материала. В этом случае, даже имея официальный сертификат, все их знания будут поверхностны, ибо для освоения технологии требуется более глубокая и объемная работа, нежели написание "Hello World"-ов. А для этого требуется время, которого сверхурочно нигде не возьмешь. Поэтому когда в резюме стоит строчка типа: С/C++, Java, Python, C#, JS, PHP, Go, Rust, то скорей всего он не владеет в достаточной степени ни одним из этих языков.
А это огромный плюс нашей памяти — делать автоматическую очистку мусора. Основной скилл для HR в этом случае не само знание, а то, что чел однажды смог хорошо разобраться с данной технологией.
Мне кажется в нашей профессии очень сильно демотивирует постоянно растущее количество технологий, которое к тому же полностью обновляется раз в два года. Всего не выучишь, за всем не уследишь, а ощущение того, что ты не на гребне волны или есть что-то чего-то не знаешь, сбивает самооценку. Тем более, что вероятно вам никогда не приведется пощупать очередной хайповый тренд, по которому следующие два года будут делать запросы HR-ы. Кроме того немаловажную роль здесь играют всевозможноые расхайпованные на конференциях и соцсетях "гуру", таким образом задающие планку. Наш специалист, сидя в зале, пытается оценить себя по навязанной шкале и то, на что он может претендовать в сравнении с выступающим.
А теперь разложим все "по понятиям".
90% "новых" хайповых технологий на деле является дерьмом, потому как:
Гуру, выступающие на конференциях или публичных площадках:
Вы реально классный специалист, если:
Вы должны осознавать:
Вопрос такой: а если патчуемый код уже заинструменчен каким-нибудь фреймворком в рантайме? Будет ли повторно вызываться инструментация фреймворка или нет?
Другой вопрос: а как вы тестируете сам процесс патчинга? HCR очень деликатная и ограниченная штука, и успешно пропатчить код может лишь в некоторых случаях. И вот у вас зафейлился патч на продакше. Что делать дальше?
Вообще, я нахожу использование такого подхода более чем странным особенно для Одноклассников. Как я себе представляю подобные системы, перезагрузка одного сервиса никак не должна влиять на общую работу: микросервисы, распределенность и все такое… Если же система монолитная или ее рестарт занимает значительное время, то можно попытаться разделить всю логику на контексты внутри приложения при помощи класслоадеров и рестартать их вбелую по мере необходимости. Или например использовать OSGi, где все это уже реализовано из коробки ввиде модулей. Но патчить на продакшне через интерфейс, предназначенный для дебага — это странное решение.
Это совершенно не зависит от способа реализации. В любой системе есть возможность написать невалидный рабочий код. И если нет человека, который контролирует всю бизнес логику, то о чем мы говорим — логика сама себя не напишет.
Все это уже доступно из коробки, например в том же Spring. Поставил одну аннотацию — получил транзакцию. Поставил пару других — вот и rest заработал. Вся эта требуха не относится напрямую к задаче BPM, или бизнес логике. И фреймворков различных для этого написано огромное количество, и кроме того любая BPMS всегда стоит поверх какой-то платформы/фреймворка: SCA, JavaEE, Spring, etc… BPM — это сугубо задача асинхронного выполнения логики с возможностью сохранения/восстановления состояния. И есть также десятки способов реализовать это. Акторы, корутины, execution graphs, etc...
Мы о какой-то конкретной системе говорим? Во всех пропиетарных системах, что я видел, состояние процесса сохраняется во внутренних таблицах, к коим не предусматривается сторонний доступ. Есть консистентный, но очень ограниченный API, который иногда позволяет манипулировать переменными процесса извне, но не контролировать само выполнение процесса.
Именно бизнес процессы, синхронизированные со временем. У стороннего сервиса есть техническое окно в котором можно оперировать. Есть планировщик, который позволяет выставлять процессам приоритет для доступа к сервису, согласно критериям. Если процесс не удается завершить по истечении окна, его нужно перепланировать на следующий день. Кроме того там много логики, касающейся SLA как с нашей стороны, так и со стороны сервисов: ответ должен быть гарантирован втечение установленного времени — если нет, то налагаются штрафы. Ну и естественно по приближении дедлайна система должна выдавать всевозможные алармы. Вобщем, на BPMS логику реализовать не осилили — пришлось писать свой модуль.
Ну вот. И теперь смотрите, насколько усложнилась задача для синхронизации одной лишь сущности. Если у вас есть несколько сущностей, или еще хуже, некая реляционная модель, связывающая их всех, то сложность процесса синхронизации увеличивается на порядки. Например, приходится производить многопроходную актуализацию, зачастую приходится отключать всяческие constraints (которые потом обратно не всегда включаются). А в некоторых случаях задача корректной синхронизации вообще неразрешима.
Тем не менее только он гарантирует постоянную консистентность всех данных. Другое дело, что не во всех кейсах это так необходимо.
P.S. не туда :(
Совершенно верно. Это если мы говорим о продукте, который покрывает конкретную, хорошо определенную и достаточно типовую область бизнес логики. И тем не менее даже здесь встают проблемы, когда сценарии клиента не соответствуют заложенным в продукте, а реализовать эти сценарии в ограниченном продукте не представляется возможным, либо связано с огромными расходами ввиду недостаточной гибкости продукта. Тут начинают появляться всякого рода велосипеды, приставленные сбоку. Другой проблемой всегда является интеграция с экосистемой клиента: здесь уже появляется слово заумное слово "архитектура", все вышеперечисленные автором проблемы и еще больше самопальных велосипедов.
Я же имею ввиду именно платформы-конструкторы как какой-нибудь Roga&Kopyta BPM SOA Suite, которые вообще не покрывают ни один из бизнес кейсов, но позиционируют себя как платформу для разработки и интеграции любых бизнес сценариев. Сомнительное утверждение, что при помощи подобного самолета можно дешевле и быстрее реализовать бизнес логику, нежели в голом коде. Тем более что от самолета там только красивая панель управления — все остальное также приходится педалить. Какие конкретно
Это все абстрактно и надумано. Конечный автомат с персистенцией в базу данных сможет реализовать любой джун. Более того, когда логика процесса изменится, всегда есть возможность контролировать состояние уже запущенных процессов, тогда как в BPMS напрямую к состоянию процесса доступа нет (проблема версионирования).
За все время работы с BPMS я не видел ни одного реально сложного бизнес-процесса. Вся сложность возникала из-за ограниченности аналиста и неумения разделить на функциональные блоки, а также потому, что в BPMN-нотации фактически присутствует "оператор goto", быстро превращающий всю схему в кашу. Там же, где сценарий требовал действительно нетривиальных вещей, таких как синхронизация со временем (realtime), раннее завершение процесса, синхронизацию процессов (race condition), каскадное завершение… — все то, что быстро реализуется в коде, но BPMS не предлагал абсолютно никаких средств, а провайдер предложил купить дополнительный продукт (ESB), который реализует эти самые "Enterprise Integration Patterns".
Декларативное описание, да еще не type-safe, да еще по имени класса/метода с сигнатурой и с wildcards… Прям как новая серия игр "Что? Где? Когда?". Тут простой рефакторинг все сразу поломает.
И главное, для чего? Есть же Proxy.newProxyInstance(), ByteBuddy и BeanPostProcessor для детерминированного инжекта.
А проблема в том, что в одной базе содержатся все марки автомобилей, которую допустим поддерживает головной офис, а в базе филиала Мухосранска локально содержатся все ремонты. Внезапно в головном офисе обнаруживается, что одна и та же модель в базе продублирована как "ВАЗ-2107" и, скажем, "ТАЗ-2107". Везде для карточки клиента использовали первый вариант, и только в Мухосранске сделали второй. Головной офис решил по-тихому расстаться с ТАЗов в модельном ряду и грохнул запись. В итоге ночью тихонько зафейлился скрипт апдейта базы Мухосранского отделения, но этого никто не заметил. Заметили через три месяца, когда система головного офиса не захотела принимать отчет с неизвестной моделью.
А вот реальная история: система сбора информации с сетки (Network Reconciliation). Ночью синхронизировались с GIS для получения новых станций и апаратов. Затем поступали данные от EMS со всеми текущими параметрами станций. В один прекрасный день образовалось несколько гигабайт зафейлившихся логов. Причина проста: GIS и наша система внезамно перешли на зимнее время, тогда как EMS всегда стоят по UTC, и в итоге начинали лить данные со станций раньше, чем мы синхронизировались с GIS, чтобы получить новый список станций. И это еще не затрагивая самой логики data reconcilliation.
Так что синхронизация баз данных — это ужасно. Тут нет универсальных решений, все что можно придумать — все плохо.
А так ли нужен монстр? Практически всегда бизнес логика достаточно простая, а процессы по большей части линейны, потому как клиент редко успешно оперирует сложными моделями. Имеет ли смысл притягивать за уши BPMS там, систему собрать из стандартных компонентов, коих в экосистеме полно — слава богу не в пустыне живем, и всю логику быстро и без напрягов наклепать вручную.
Кроме того, BPMN — это всего лишь стандарт, для того, чтобы он завертелся, необходима какая-никакакя платформа, содержащая в себе визуальные средства разработки, отладки, мониторинга, компоненты интеграции с внешними системами, компоненты работы с моделью данных, мепперы, бизнес-правила, языки сценариев, API для работы сценариев, средства разработки пользовательских интерфейсов (формочек), система управления пользователями, пользовательский портал, etc, etc… Какой-нибудь SOA Suite. Более-менее рабочий продукт, содержащий все вышеперечисленное, будет обязательно пропиетарным. И разработка под него станет ни чем не выгоднее, чем без оного. Это такой красивый швейцарский нож: вроде бы все есть, все как бы можно сделать, но чего не коснись — все неудобно и плохо: ни хлеб нормально не порезать, ни ногти постричь, ни винт открутить, ни вино откупорить.
Это мечта любого заказчика — ты мне дай такой внятный конструктор, на котором я бы смог в любой момент поменять параметр, подправить мышкой бизнес-логику — и все без всяких этих ваших джав, девопсов и прочей фигни. Реально же получается, что заказчику под видом архитектуры задвигают кучу всякого пропиетарного и дорогого барахла типа BPMN, потом он судорожно ищет дорогого специалиста, кто бы мог это все поднять дело и запустить. А затем, не осилив BPMN и Rules Engine, жестко подседает на провайдера, который не стесняется заламывать цены, ибо на рынке всего полтора специалиста по данной системе. И это еще самый оптимистичный сценарий.
И, да, хорошие программисты идеально разбираются в предметной области, зачастую лучше, чем сам заказчик. Понимают специфику работы, нужды заказчика, и сами предлагают оптимальные решения для бизнеса. И да, заменить такого программиста сложно, и это нормально — потеря квалифицированных кадров в любой отрасли негативно отражается на производстве.
Ну вот по поводу общей базы данных: когда каждая система имеет свою копию, относящуюся к одной бизнес сущности, возникает вопрос синхронизации данных и кто является изначальным владельцем. Многие запускают ночные процессы синхронизаций, которые наутро выдают огромные портянки неконсистентных данных (это в лучшем случае), некоторые пробуют онлайн синхронизацию. Но в большинстве случаев никто не заморачивается и просто дают dblink к своей базе — типа сами ищите там все, что вам нужно.
Совершенно верно. У них нет нормальных вещей. Если лет 10 назад в H&M можно было дешево и нормально одеться, то сейчас там висит какой-то улично-молодежный треш для хипстеров, роллеров, мэтросексуалов и прочих неформалов. Причем тенденция затронула не только H&M, но и другие марки: Zara, C&A, Springfield… Извечная боль — найти на мой рост нормальные штаны Straight адекватной длины и рубашку с длинными рукавами.
P.S. AI, проанализировав данные со всех продаж, и подумав какое-то время, выдал неожиданное решение: "может быть вам пора бы уже начать шить нормальную одежду?"
Причина того, что нет более-менее нормального стандартизованного стека технологий разработки. Spring я привел лишь в качестве примера, я сам его недолюбливаю. Однако он интегрируется практически со всеми технологиями, предлагает простой уровень абстракций для управления, и прямо из коробки годен практически для любого проекта. Сегодня пишут на спринге, и завтра тоже будут писать на нем.
Во фронтэнде же не существует более-менее универсального стека разработки. Сегодня есть 50 технологий, хреново интегрирующихся между собой, завтра их будет 150. Вчера был ангуляр, сегодня реакт, завтра какой-нибудь Vue.js или еще 10 других. Вы никогда не поспеете за всем этим. К тому же ваше рабочее время будет тратиться на изучение всего этого дерьма, вместо того, чтобы решать поставленные задачи. Вот я и говорил выше, что согласно моей практике, за последние 10 лет фронтэнд разработка не стала ни быстрей, ни качественней, ни дешевле, тогда как задачи практически не изменились.
Ой ли? На фронтенд даже не постеснялись притащить целый браузер ввиде электрона ради поделки с парой кнопочек. Вот недавняя статья на этот счет. Веб приложения постоянно пухнут, нещадно жрут память и тормозят, при всем том, что их функциональность особо сильно не меняется. И это как бы никого не волнует. Никто не стесняется ради красивой кнопочки подключать сразу всю библиотеку, или ради пары иконок тащить весь фонт.
Так что причина не в этом, а в том, что это вся экосистема JS — это куча мелких говноподелок, склепанных школьниками на коленках. А все, более-менее серьезное в JS было сделано крупными компаниями для внутреннего использования и щедро подарено в оперсорс.
Вы какие-то фантастические аргументы привели ей-богу! Основной аргумент — если ты даже не представляешь что такое блокчейн, и для чего он нужен, то с вероятностью 99% тебе он не нужен совсем. Как правило блокчейн требуют, потому что это модно, и всем хочется соответствовать тренду. Это слово-паразит, которое нужно выжигать каленым железом, что даже боялись заикнуться о нем! 10 лет назад, я помню, таким паразитом был "cloud". Потом Agile… Гипермемы какие-то! Область применения блокчейна очень ограничена, в 100 или 1000 раз меньше, чем об этом говорят. И кстати, убедился на собственном опыте, больше всех говорят о блокчейне те, кто меньше всего представляет, что это такое и с чем его едят.
Это все очень хорошо, но реализация сего злодейского плана потребует на порядки больше затрат, нежели ожидаемая выгода, затрагивает большое количество сфер человеческой деятельности, не связанных с медиаконтентом, идет вразрез с основами прав и свобод человека, а по долгосрочности и рискам не сопоставим ни с одним проектом человечества.
А вот что реально будет и уже происходит — это глобальное удешевление контента и его агрегация в пакеты при помощи глобальных сервисов доставки. За небольшую абонентскую плату ты получаешь огромное количество легального мяса, доступного везде и всегда при помощи всего одного клика. Идея в том, чтобы оплата сама по себе напрягала меньше, чем вся эта возня с пиратскими штучками. Только так можно победить пиратство.
Хорошо помню "Бомжика" на Спектруме. После статьи нагрянула какая-то восьмибитная ностальгия 90-х, когда все было теплым и ламповым. Вот самый ламповый онлайн эмулятор Спектрума: http://torinak.com/qaop