Может очень бедненько выглядеть, т.к. такому крассному специалисту особо не к чему.

Затрати на ESB-based-прототип, написаний на Java + Deployment, займав приблизно в 10 разів більше часу й утричі більше ресурсів, ніж такий самий прототип, побудований за допомогою Dell Boomi iPaaS-рішення.

помню, Ruby on Rails в свое время так активно рекламировали :)

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

Нет таких, просто нет. Любой человек может проявлять токсичность в определенных условиях.

 ок, перефразируем: старайтесь выявлять людей, которые будут токсичны в контексте данного проекта. Так лучше?

А чем Cypress плох?

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

Из требований бизнеса: надо чтобы все цифирки на всех страничках были консистентные :)

не показывайте не те странички! :)

Некоторые из нас уже практиковались такой архитектурой ещё до того как все начали называть это microservices

Service-Oriented Architecture предыдущая волна называлась вроде.

Микросервисы очень плохо реализуют транзакционность.

Просто не нужно пытаться микросервисами сэмулировать монолит. Или осознать и принять микросервисную модель, или продолжать строить монолит.

В комментах, смотрю, предлагают базу шарить между микросервисами — не стоит. Иногда работает, но нужно очень хорошо знать что делаешь, что в большинстве случаев не факт.

Плохая работа с согласованностью данных между базами данных.

Не плохая, а другая. Надо быть готовым что 100% consistency в конкретный момент в целом никогда не будет. Будет eventual со всеми вытекающими: мониторить нужно задержку этой eventuality, сверять согласованность по данным изменившимся ранее этой задержки и т.п.

Согласованность, ИМХО, основная сложность отхода от монолитной ACID модели данных с микросервисами или без них.

Хорошая новость — эту проблему все равно нужно решать на границах системы (интеграция с другмими системами) или с ростом сложности системы.

Если используются несколько баз данных, то надо использовать 2PC протокол.

НЕТЪ! 2PC мертв. Читаем, например, dataintensive.net если пропустили.

Приглашаю всех делиться своими наблюдениями по поводу микросервисов!

Знаете ли вы в первую очередь ЗАЧЕМ вам нужны микросервисы? По вопросам не похоже. Может вам и не нужно? Уже следующий вопрос — как их дробить и строить.

Причин может быть несколько, и даже одновременно:

— менеджмент слаб в развитии персонала, фидбека действительно не давали и вины твоей в этом мало. Ну в следующий раз до конца ИС не расслабляйся.
— фидбек давали, но ты его не понял. Посмотри на историю переписки с нынешним знанием — были ли признаки? То, что ты работал удаленно не упрощало коммуникацию в этом смысле, но бывают и на онсайт плохо считывают ситуацию и командную динамику.
— ты не вписался, и фидбека не давали потому что не видели смысл в продлении отношений. Типа проявит до конца ИС — может подумаем, а так — нет.
— что-то поменялось в организации. Например, победила идея развития автоматизации тестирования, и твоя позиция оказалась излишней.
— может и как Oleg Kotok говорит, компания паразитирует на низкоквалифицированном труде по заниженным расценкам ИС, хотя учитывая накладные расходы на поиск и введение в курс такая стратегия выглядит сомнительной

Дебаг подключать с брякпойнтами наверное действительно очень плохой smell.

Не очень понятен этот твит в контексте моего вопроса. Даже если воспроизводить на тестовой среде, все равно полезно посмотреть что именно по продакшин дампу.

А от якість картинки, ретина — на це наврядчи впливає.

сам пробовал?

Ну вот вроде в заметке и пытаются описать как это делать систематично. А не знаете что делать с дампами — ну не снимайте их тогда, действительно :)

Автор рекомендует делать coredumps в production окружении. Напомню, это антипаттерн — debug должен быть где-угодно, но не в реальном «боевом» окружении.

хм, в чем проблема следать дамп дохлого процесса, как автор предлагает? Почему дебаг не должен быть на продакшине?

freelance == independent contractor. Удаленность зависит больше от типа работ. В любом случае поправлять топиккастера было некорректно, имхо.

Тоже мне доказательство :) Ну поищи в картинках программера или тестера и скажи на какой странице будут стойла лидеров рынка изображены.

Фриланс — это не есть удаленная работа.

Та то ж читать нужно и разбираться в этой всякой казуистике

Но в большинстве своём мало кто идёт в суд и тупо забивает)

насколько я понимаю, сами голландцы таки забивают на подобные бредовые пункты и идут себе спокойно дальше программить на питоне. Если у предыдущего работодателя будет претензия — это ему прийдется через суд взыскивать штраф, а суды обычно в таких ситуациях на стороне работника (опять же, не из личного опыта). Язык программирования — это уж через чур, но многие работодатели грешат слишком общими non-competitive clause. Лучше такие вещи, конечно, вычитать и убрать, игнорируя нытьё HR что договор типовой.

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

a) не связывайтесь с агенствами — зачем вам посредник который долбит компанию и пытается продать вас за +10-20% вашей зп каждый месяц в течении 1-2 лет, в таком случае компании вообще выгодно вас уволить на испыталке что бы не платить агенству

Из своего опыта или теоретически? Как-бы если не формошлепство, а натуральное АйТи, то выхлоп от найма начнется намного позже испытательного срока. А 10-20 процентов — это мелочи по сравнению с поиском новых сотрудником, и потерей времени на уволенного. Знаю людей вполне довольных работой через агенства, так что сомнительная рекомендация в целом (сам не пробовал).

в) не релокейтесь из украины в какую то ноунейм компанию — большие компании с именами не будут вас кидать.

Всякое бывает. Большим компаниям с сильным брендом и командой юристов кидки сходят с рук проще, так что не уверен в универсальности совета. Но в среднем может и поменьше риски.

Собственно неизменяемость это хорошо, но это хорошо для дата-классов, которые есть в Скале и Котлине, а в джаве нету.

 то есть, в Котлине и Скале можно продолжать анемичную модель использовать, а в Джаве нет? А если Джава с Ломбоком?