ну, оригинальная статья не говорит о том, что не надо саспендится в synchronized секции — это уже придумал переводчик. Статья про то, что привычные жависту примитивы синхронизации в контексте корутин не работают так, как ожидается жуниорами. То есть про то, что надо пользоваться другими средствами. А так совершенно верно — делать функцию suspend без явного разрыва имеет смысл только если разрыв ожидается неявно в одном из вызовов внутри.
переведена статья о том, что синхронизация jvm уровня просто НЕ работает в корутинах (без объяснения, чем кооперативная многозадачность отличается от принудительной). Переводчик зачем-то добавил, что "синхронизацию" лучше использовать только при отсутствии точек останова. Сразу вопрос — если она (synchronized секция) не работает вообще, то....???? Либо я не понял статью, либо переводчик. И да, "синхронизация" — это, в том числе, и мьютекс.
корутины — это невытесняющая многозадачность, они локальны.
модель акторов совсем про другое — это про изоляцию и прозрачность размещения, они распределенны.
Сравнивать можно в какой-то мере Akka Streams с Koroutines Flow, но не ядро акки с корутинами — они совсе про разное.
Работаю в инвестиционном банке скала программистом. Три месяца на распбери 4 через citrix workspace, для себя в нерабочее время тоже хватает. ОЗУ 4гб, разогнан до 2ггц, вентилятор через транзистор при нагреве (нечасто), два дисплея в портрете.
Это странный подход — не найти позиций по Скале и говорить, что их нет. Не программировать в продакшн на скале и рассуждать о ее преимуществах и недостатках. Как будто не читал, но осуждаю.
Мне на Скалу приходили рекрутеры неколько крайних лет, хотя в моем профайле скалы нет. А текущую работу (моя первая работа на Скале) я получил, прийдя на собеседование по "Жава-сеньор" где мне сказали, что они скалистов не ищут, потому что их не найти, что джавы у них нет, а надо быстро подучить скалу (тут сотни программистов на скале). И вот когда видишь эту самую скалу не в курсе Одерского, а на кровавом энтерпрайзе — микросервисы и никакого датасатанизма — то многие вещи видятся по-другому.
вы рассуждаете исходя из теории, но не знаете всей подноготной. Проблема совместимости в скала на удивление острая и решается совсем не так, как в мире джавы. В первую очередь это совместимость на уровне ABI, а не API. В джаве такого просто представить сложно. У вас log4j будет работать на жаве от 1.2 до 15 и далее, а в скале минорный апдейт и молитесь, чтоб был опенсорс и мейнтейнеры обновили со скалы 2.11 на 2.12 и КАЖДАЯ зависимость будет вас задерживать.
Переехал по личным причинам из Финляндии. Статья весьма дизориентирующая. Зарплата "в среднем по больнице" странная. Когда я искал полгода назад, то показывали цифры вдвое больше приведенных тут. Особенность, что при указании зарплат кто-то дает до налогов, а кто-то после и это вносит неразбериху. Сами местные озвучивают обычно свою зарплату после налогов, а HR — до. Понятное дело, что если сеньору предложить 500 тыщ даже после налогов, то просто вешай трубку и все дела — без шуток. Предложения есть получше всегда. Джунам дадут еще меньше, миддлам может подойдет. Зарплаты, тем не менее, значительно ниже "более развитых" стран. Рассказывают, что и траты тут значительно меньше. Траты, без сомнения, меньше, но соотношение явно не в пользу работника — есть статистика weighted income per capita и Венгрия там в числе последних в Европе. Когда у меня HR узнавали, сколько я получал в Хельсинки и каковы мои ожидания (пониже), то был слышен грохот падения со стула и кто-то искал успокоительное. Плюс зарплата в форинтах все же не то же самое пока что, что зарплата в евро.
Я сравниваю с 10 годами в Финляндии, так что тут есть некоторый перекос, вероятно, непонятный работающим в ex-СССР.
Соотношение работа-отдых. Гораздо хуже, меньше доверия, плюс час рабочего времени минимум.
Иностранцев мало. Оно и понятно — сюда едут либо на пенсию либо по ошибке, либо по личным обстоятельтвам. Местные сами массово валят за рубеж, с чего бы иностранцам сюда? Хотя едут китайцы — но по другому поводу.
Про английский. Местные говорят, что мало кто владеет английским и все учат немецкий. На практике в Будапеште чаще можно попасть на сносно говорящего по-английски даже в пельменной. Это не относится к госучереждениям — там английский редко.
Про ксенофобию. Если ты не цыган — то всем по барабану. Цыган не любят. Цыганами пугают. Статистику по криминалу не замалчивают, в отличие от остального ЕС. Но! Цыгане работают тут (хотя для местных это постоянный сюрприз). И, глядя на "беженцев" Хельсинки, я склонен думать, что проблема преувеличена. Жители Москвы или СПб могут только усмехнуться. Русских здесь очень мало, так что экзотика — никакого негатива. СССР, понятно, ненавидят — но абстрактно. Украинцы работают вчерную — никто их не видит за пределами колхозов и стройплощадок. Так что "ксенофобия" выражается в отсутствии открытой ЛГБТ+ пропаганды, скрытой и открытой рекламы "мультикультуризма", отсутствии людей в традиционной средневековой одежде и с такими же нравами и наличием общепринятных для всех социальных норм. Кому-то это по нраву, кому-то нет. Я бы не стал называть это важным фактором при решении о переезде. Если кто впервые в ЕС едет — то это лучше почувствовать на себе, а не на хабре, а дело это не на первом месте в списке пока. Ну есть люди, которые любят ванильное мороженное, но не любят черничное — тут таких не порицают и не заставляют любить все одинаково, до тех пор пока они не плюют в лоток с нелюбимым блюдом, образно говоря. Как долго это продлится — неизвестно. Как долго это или противоположное продлится в других частях света — тоже.
Про язык — он очень сложный, а учить его смысла нет (если что — я финский выучил и рад) Валят отсюда даже местные, а как "легализация ЕС" он не канает — хотя формально он нужен для гражданства, по неофициальным каналам сообщают, что гражданство получить без "расово чисто крови" нереально. Есть кровные родичи в роду — учи язык и получай паспорт. Нет родичей — иди гуляй. Кстати, даже ипотеку не дадут — причем, по закону какому-то (купить жилье можно за полную сумму).
Ну, как-то так. Как часть хитрого плана может проканать. Иначе — только если обстоятельства поджимают.
Обидно, что перевод заминусовали. Цель перевода — донести, что там "за бугром" и о чем там спорят (и спорят много), так как есть вероятность, что коснется многих читающих. Надо быть готовым. Плюс за работу по отбору статьи и переводу!
Вообще-то непонятно, почему было принято архитектурное решение CQRS/ES. Логики не прослеживается именно в описании выбора. Дано:
1) пришел готовый проект, который писали по CRUD.
2) Он работает плохо. Симптоматика кратко дана.
3) ?????
4) Поэтому решили делать на CQRS/ES.
Почему плохо подходит CRUD? Может, это проблема реализации, а не подхода? Как CQRS/ES была признана способной решить именно эти проблемы, помимо "поговорили с коллегами"? Что получилось сделать хорошо, помимо описанных в статье проблем? Это хорошо, что тут CQRS/ES подошел отлично, исходя из опыта проекта, но из статьи совсем не понятно, почему.
Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться — это их основное отличие, диктующее способ применения.
Строго говоря, в EU отслеживание пользователя для его профилирования и таргетинга должно быть явно указано и согласие получено обязательно. Знаменитый Cookies Law совсем не про куки, а про любые средства отслеживания — его стоит прочитать. Просто куки стали широко известны как самое используемое средство.
Подготовиться к собеседованию опытному разработчику не так сложно. Даже дурацкие алгоритмические задачи подтягиваются за недели, а не месяцы. Навык не бубнить — если вдруг стресс — за пару собеседований. А если человек не подготавливается — выше риск, что не будет ценить полученное, конкретно эта работа ему может не понравится и он уйдет. Компании взвешивают все риски, а не только технические знания. Мне вот недавно сказали: "наши ценности не совпадают с Вашими". И совершенно верно сделали, что не взяли.
В корне не верно представление, что не взять спеца — трагедия. Компания может позволить себе НЕ взять хорошего спеца, а вот взять плохого — чаще всего не может. Так что отсеивать хороших кандидатов — нормальная практика. Мы, работники, несмотря на весь хайп — не полубоги, которых надо понять и простить, накормить и кофеем напоить. И проблемы нет — если не берут на одну позицию, то возьмут на другую. Не сейчас — так потом. С голоду не мрём вроде, на икорку хватает. Хочется черной вместо красной? Готовимся. Интерес обоюдный.
Идеальное собеседование — это выше вероятность, что в компании будет комфортно. Если собеседование прошло плохо — наверное, это не то место для собеседуемого и оно лучше подойдет кому-то другому. Мы же разные все.
По поводу "прыгунов" — это задача HR для отсева и вроде справляются они неплохо. И на самом деле "прыгунам" проще там, где надо самому подаваться, а самые "жирные" места открываются, когда тебя ищут, зовут и реферят. Тогда и собеседование другое, там не будет особых неожиданностей, ибо зовут четко по профилю и знают, что кандидата "на вшивость" проверять не надо.
И собеседуют по-разному. Меня сейчас судьба вынесла на собеседования в другой стране, без референсов, без привелегий и странно, что на мои 20 лет конкретного опыта смотрят с подозрением и спрашивают про хеш мапы — но это девиация карьерного роста и се ля ви. Еще раз — по разному собеседуют и то, что не берут — это норма осторожного поведения, а не трагедия для обоих сторон.
пул идентификаторов идея очень правильная (и без распределенной базы работает, где нет autoincrement), но интервалы или (в общем случае) стратегии генерации должен выдавать глобальный координатор — редко, но метко. Может, какие-то стратегии общего консенсуса тоже сработают — не уверен, что это будет приемлимо быстро. Может быть ситуация, когда ноды подключаются и отключаются и простые решения с "четным-нечетным" перестают работать.
Стоит отметить, что батч привязаны к соединению и к транзакции. Таким образом, в управляемом окружении (например, обработчике веб-запроса сервера приложений) батчи будут выполняться для каждой транзакции отдельно. То есть если тысяча HTTP запросов предполагает записывание по строке данных, то никаких батчей и выигрышей не будет.
это факт — именно это и написано в "от переводчика", а в переводе этого нет.
ну, оригинальная статья не говорит о том, что не надо саспендится в synchronized секции — это уже придумал переводчик. Статья про то, что привычные жависту примитивы синхронизации в контексте корутин не работают так, как ожидается жуниорами. То есть про то, что надо пользоваться другими средствами. А так совершенно верно — делать функцию suspend без явного разрыва имеет смысл только если разрыв ожидается неявно в одном из вызовов внутри.
переведена статья о том, что синхронизация jvm уровня просто НЕ работает в корутинах (без объяснения, чем кооперативная многозадачность отличается от принудительной). Переводчик зачем-то добавил, что "синхронизацию" лучше использовать только при отсутствии точек останова. Сразу вопрос — если она (synchronized секция) не работает вообще, то....???? Либо я не понял статью, либо переводчик. И да, "синхронизация" — это, в том числе, и мьютекс.
корутины — это невытесняющая многозадачность, они локальны.
модель акторов совсем про другое — это про изоляцию и прозрачность размещения, они распределенны.
Сравнивать можно в какой-то мере Akka Streams с Koroutines Flow, но не ядро акки с корутинами — они совсе про разное.
Работаю в инвестиционном банке скала программистом. Три месяца на распбери 4 через citrix workspace, для себя в нерабочее время тоже хватает. ОЗУ 4гб, разогнан до 2ггц, вентилятор через транзистор при нагреве (нечасто), два дисплея в портрете.
Это странный подход — не найти позиций по Скале и говорить, что их нет. Не программировать в продакшн на скале и рассуждать о ее преимуществах и недостатках. Как будто не читал, но осуждаю.
Мне на Скалу приходили рекрутеры неколько крайних лет, хотя в моем профайле скалы нет. А текущую работу (моя первая работа на Скале) я получил, прийдя на собеседование по "Жава-сеньор" где мне сказали, что они скалистов не ищут, потому что их не найти, что джавы у них нет, а надо быстро подучить скалу (тут сотни программистов на скале). И вот когда видишь эту самую скалу не в курсе Одерского, а на кровавом энтерпрайзе — микросервисы и никакого датасатанизма — то многие вещи видятся по-другому.
вы рассуждаете исходя из теории, но не знаете всей подноготной. Проблема совместимости в скала на удивление острая и решается совсем не так, как в мире джавы. В первую очередь это совместимость на уровне ABI, а не API. В джаве такого просто представить сложно. У вас log4j будет работать на жаве от 1.2 до 15 и далее, а в скале минорный апдейт и молитесь, чтоб был опенсорс и мейнтейнеры обновили со скалы 2.11 на 2.12 и КАЖДАЯ зависимость будет вас задерживать.
Переехал по личным причинам из Финляндии. Статья весьма дизориентирующая. Зарплата "в среднем по больнице" странная. Когда я искал полгода назад, то показывали цифры вдвое больше приведенных тут. Особенность, что при указании зарплат кто-то дает до налогов, а кто-то после и это вносит неразбериху. Сами местные озвучивают обычно свою зарплату после налогов, а HR — до. Понятное дело, что если сеньору предложить 500 тыщ даже после налогов, то просто вешай трубку и все дела — без шуток. Предложения есть получше всегда. Джунам дадут еще меньше, миддлам может подойдет. Зарплаты, тем не менее, значительно ниже "более развитых" стран. Рассказывают, что и траты тут значительно меньше. Траты, без сомнения, меньше, но соотношение явно не в пользу работника — есть статистика weighted income per capita и Венгрия там в числе последних в Европе. Когда у меня HR узнавали, сколько я получал в Хельсинки и каковы мои ожидания (пониже), то был слышен грохот падения со стула и кто-то искал успокоительное. Плюс зарплата в форинтах все же не то же самое пока что, что зарплата в евро.
Я сравниваю с 10 годами в Финляндии, так что тут есть некоторый перекос, вероятно, непонятный работающим в ex-СССР.
Соотношение работа-отдых. Гораздо хуже, меньше доверия, плюс час рабочего времени минимум.
Иностранцев мало. Оно и понятно — сюда едут либо на пенсию либо по ошибке, либо по личным обстоятельтвам. Местные сами массово валят за рубеж, с чего бы иностранцам сюда? Хотя едут китайцы — но по другому поводу.
Про английский. Местные говорят, что мало кто владеет английским и все учат немецкий. На практике в Будапеште чаще можно попасть на сносно говорящего по-английски даже в пельменной. Это не относится к госучереждениям — там английский редко.
Про ксенофобию. Если ты не цыган — то всем по барабану. Цыган не любят. Цыганами пугают. Статистику по криминалу не замалчивают, в отличие от остального ЕС. Но! Цыгане работают тут (хотя для местных это постоянный сюрприз). И, глядя на "беженцев" Хельсинки, я склонен думать, что проблема преувеличена. Жители Москвы или СПб могут только усмехнуться. Русских здесь очень мало, так что экзотика — никакого негатива. СССР, понятно, ненавидят — но абстрактно. Украинцы работают вчерную — никто их не видит за пределами колхозов и стройплощадок. Так что "ксенофобия" выражается в отсутствии открытой ЛГБТ+ пропаганды, скрытой и открытой рекламы "мультикультуризма", отсутствии людей в традиционной средневековой одежде и с такими же нравами и наличием общепринятных для всех социальных норм. Кому-то это по нраву, кому-то нет. Я бы не стал называть это важным фактором при решении о переезде. Если кто впервые в ЕС едет — то это лучше почувствовать на себе, а не на хабре, а дело это не на первом месте в списке пока. Ну есть люди, которые любят ванильное мороженное, но не любят черничное — тут таких не порицают и не заставляют любить все одинаково, до тех пор пока они не плюют в лоток с нелюбимым блюдом, образно говоря. Как долго это продлится — неизвестно. Как долго это или противоположное продлится в других частях света — тоже.
Про язык — он очень сложный, а учить его смысла нет (если что — я финский выучил и рад) Валят отсюда даже местные, а как "легализация ЕС" он не канает — хотя формально он нужен для гражданства, по неофициальным каналам сообщают, что гражданство получить без "расово чисто крови" нереально. Есть кровные родичи в роду — учи язык и получай паспорт. Нет родичей — иди гуляй. Кстати, даже ипотеку не дадут — причем, по закону какому-то (купить жилье можно за полную сумму).
Ну, как-то так. Как часть хитрого плана может проканать. Иначе — только если обстоятельства поджимают.
Обидно, что перевод заминусовали. Цель перевода — донести, что там "за бугром" и о чем там спорят (и спорят много), так как есть вероятность, что коснется многих читающих. Надо быть готовым. Плюс за работу по отбору статьи и переводу!
Вообще-то непонятно, почему было принято архитектурное решение CQRS/ES. Логики не прослеживается именно в описании выбора. Дано:
1) пришел готовый проект, который писали по CRUD.
2) Он работает плохо. Симптоматика кратко дана.
3) ?????
4) Поэтому решили делать на CQRS/ES.
Почему плохо подходит CRUD? Может, это проблема реализации, а не подхода? Как CQRS/ES была признана способной решить именно эти проблемы, помимо "поговорили с коллегами"? Что получилось сделать хорошо, помимо описанных в статье проблем? Это хорошо, что тут CQRS/ES подошел отлично, исходя из опыта проекта, но из статьи совсем не понятно, почему.
Ну и в самом CQRS сливать Event и Command в одной транзакции — это достаточно сильное искажение архитектуры. Command может быть проигнорирован, а Event обязан выполниться — это их основное отличие, диктующее способ применения.
Строго говоря, в EU отслеживание пользователя для его профилирования и таргетинга должно быть явно указано и согласие получено обязательно. Знаменитый Cookies Law совсем не про куки, а про любые средства отслеживания — его стоит прочитать. Просто куки стали широко известны как самое используемое средство.
Какие еще варианты перевода "Eventual consistency" есть? Хотелось бы иметь консенсус по именованию...
Претенциозно. Если это "мифы" для Альфы, то это не значит, что в других банках все так же. Из личного опыта.
Подготовиться к собеседованию опытному разработчику не так сложно. Даже дурацкие алгоритмические задачи подтягиваются за недели, а не месяцы. Навык не бубнить — если вдруг стресс — за пару собеседований. А если человек не подготавливается — выше риск, что не будет ценить полученное, конкретно эта работа ему может не понравится и он уйдет. Компании взвешивают все риски, а не только технические знания. Мне вот недавно сказали: "наши ценности не совпадают с Вашими". И совершенно верно сделали, что не взяли.
В корне не верно представление, что не взять спеца — трагедия. Компания может позволить себе НЕ взять хорошего спеца, а вот взять плохого — чаще всего не может. Так что отсеивать хороших кандидатов — нормальная практика. Мы, работники, несмотря на весь хайп — не полубоги, которых надо понять и простить, накормить и кофеем напоить. И проблемы нет — если не берут на одну позицию, то возьмут на другую. Не сейчас — так потом. С голоду не мрём вроде, на икорку хватает. Хочется черной вместо красной? Готовимся. Интерес обоюдный.
Идеальное собеседование — это выше вероятность, что в компании будет комфортно. Если собеседование прошло плохо — наверное, это не то место для собеседуемого и оно лучше подойдет кому-то другому. Мы же разные все.
По поводу "прыгунов" — это задача HR для отсева и вроде справляются они неплохо. И на самом деле "прыгунам" проще там, где надо самому подаваться, а самые "жирные" места открываются, когда тебя ищут, зовут и реферят. Тогда и собеседование другое, там не будет особых неожиданностей, ибо зовут четко по профилю и знают, что кандидата "на вшивость" проверять не надо.
И собеседуют по-разному. Меня сейчас судьба вынесла на собеседования в другой стране, без референсов, без привелегий и странно, что на мои 20 лет конкретного опыта смотрят с подозрением и спрашивают про хеш мапы — но это девиация карьерного роста и се ля ви. Еще раз — по разному собеседуют и то, что не берут — это норма осторожного поведения, а не трагедия для обоих сторон.
а почему Spring Boot только? Нынче ж важен интерфейс, а не реализация. Сейчас в банках и Quarkus есть.
пул идентификаторов идея очень правильная (и без распределенной базы работает, где нет autoincrement), но интервалы или (в общем случае) стратегии генерации должен выдавать глобальный координатор — редко, но метко. Может, какие-то стратегии общего консенсуса тоже сработают — не уверен, что это будет приемлимо быстро. Может быть ситуация, когда ноды подключаются и отключаются и простые решения с "четным-нечетным" перестают работать.
Стоит отметить, что батч привязаны к соединению и к транзакции. Таким образом, в управляемом окружении (например, обработчике веб-запроса сервера приложений) батчи будут выполняться для каждой транзакции отдельно. То есть если тысяча HTTP запросов предполагает записывание по строке данных, то никаких батчей и выигрышей не будет.
все просто — возможности нет
Данные велосипеды делаются под эгидой Eclipse и Spring, что внушает некоторое доверие.
Речь о драйвере баз данных, а не о фреймворка в целом