Слабенько. Открываем Макконнелла и там гораздо подробнее, кейсов больше и лучше описано. В 21 веке, когда эта тема обсосана со всех сторон, с исследованиями и не только, такая статья вызывает недоумение.
откуда цифра и знания про рациональность джунов (да и людей в целом)? зачем работодателю платить копейки, тратить силы/деньги на обучение, чтобы потом начать всё заново? (жадных и отбитых не берем в расчет, видимо про них речь была). Ну или взять потом мидла, которого надо опять обучать, но уже 2х? Здесь срабатывает арбитраж (исключения не в счет): лучше платить джуну по сетке, чтобы он потом не свалил, а за повышение (даже можно сделать меньше по рынку) дорос до мидла и т.д. Проработает какое-то время, нагреет местечко и так можно тянуть и до старшего, ведущего и т.д. Терять хорошие кадры не выгодно.
Откуда вы это взяли, что джунов избегают? Работодатель не идиот. Он бы может и хотел суперведущих и бесплатно, но есть же еще и реальность: стоимость, усталость, выгорание, повышение, работа не по статусу, заменяемость. В армии же не только офицеры, кто-то и горшки должен обжигать.
К примеру, у меня в команде старшие и ведущие и я рассматриваю джунов и стажеров. И это не эффект выжившего, такого полно в командах рядом. Просто никто не готов абы кого брать, даже если ты 5 гамбургов кончил )
но если он погиб по ООМ, то значит не нарушается? он же погиб, значит партицию не слушает, значит ею завладеет после таймаута кто-то другой.
а если погиб только консьюмер, а обработка продолжается, то опять всё в ваших руках - почините консьюмер, чтобы не погибал. Или чтобы погиб, а в месте с ним и обработка, в контролируемый вами таймаут.
тут нужно рассматривать систему не в вакууме, а в реальности.
Есть такое исследование - FLP (Fischer, Lynch, Paterson). Вывод из него следующий:
В асинхронной распределённой системе с хотя бы одним ненадёжным процессом не существует детерминированного алгоритма, гарантирующего достижение консенсуса за конечное время.
То есть всё? расходимся? не занимаемся построением асинхронных, распределенных систем?
Конечно же нет. Добавляем в систему таймауты, рандомизацию и отказоустойчивость и в большинстве случаев у нас все хорошо.
Т.е. если мы берем в расчет не какую-то внешнюю не доверенную сеть, а внутреннюю (а мы ею управляем, начиная от брокеров и заканчивая клиентами), то все в наших руках.
Конечно могут быть случаи, когда "кривой" клиент не отреагировал на событие ребаланса, но что вам мешает довести его до правильных кондиций? Если вы не укладываетесь в таймауты (обычно в библиотеках это 5 минут), то что мешает его увеличить?
В этом вы правы. Для кафки очень много клиентских библиотек, где все описанное реализовано и доступно через удобные абстракции. Но всё таки, при работе с какой-то технологией, при решении каких-то особых задач, рано или поздно приходится выходить за рамки абстракций и погружаться в тонкости. Да и вообще, в целом хорошо понимать как-что работает, даже если реализовывать не придется. Надеюсь, что в этом моя статья будет полезна.
Конкретно я пишу на c#/.net. Для .net толковая библиотека - confluent.kafka.net (правда сейчас мы мигрируем на прослойку поверх grpc - об этом есть статья в блоге Озона). Conflient.kafka.net - библиотека вокруг неуправляемого кода (поверх librd) и у нее есть свои приколы и проблемы (удивляюсь, почему до сих пор нет достойной родной библиотеки).
Посоветовать язык сложно - зависит же от круга решаемых задач. Для микросервисной разработки c# весьма хорош. Мощный, выразительный, мультипарадигменный язык. С широким спектром и поддержкой фреймворков и инструментов.
соглашусь с @Derfirm. По времени занимает по разному, в зависимости от среды, ресурсов, числа консьюмеров, протокола, числа топиков, партиций и т.д. Тут надо сравнивать в одной и то же среде разные протоколы и разные сценарии. Например, eager vs coop-sticky и добавление/удаление n-консьюмеров.
В яве хочель портянку из ифов делай, хочешь пробрасывай - лови. Хочешь любым другим способом. А стектрейс наоборот удобная штука - сразу показывает где проблема, еще и в строчку ткнет
опять "в хорошем смысле", "жизнеспособен". Сплошная вкусовщина.
Но на самом деле "Просто" - объективная характеристика. Из математики, из теории автоматов. Ее можно измерить. И, самое главное, она хорошо коррелирует с субъективной простотой (можно почитать исследования "What makes rules complext" или McCabe "Cyclomatic complexity") Мы должны разделять простоту объективную и субъективную. Субъективная обычно основывается на знакомости. Знаешь код, знаешь шаблон - для тебя легко. Не знаешь, новое - сложно.
Берешь переписываешь - становится легко. Но упростил ли ты или просто узнал? Стало ли лучше объективно?
Автор, написав, сей опус, конечно не задумывался об этом.
И кто виноват? c#? А есть вообще язык, на котором можно только правильные вещи делать? А что такое правильные? А пользоваться в широком спектре им можно будет?
Надо сначала тему изучить, а потом лезть. Интерфейс - это контракт, а не наследование. А то еще напиши 'ой смотрите, говорят множественного наследования нет, а вон какая дичь - несколько интерфейсов'
Предвзятость подтверждения. Эффект якоря.Автор упрощает и подгоняет реальность, выставляя теорию каким-то пятым колесом.
Сможете ли вы накачать мышцы без теории? скорее всего выставите себя посмешищем и объектом роликов в интернете. Практика/опыт это наработка интуиции, когда вы можете видеть шаблоны не особо задумываясь. Решать задачи можно сказать с лёту. Это очень важно. Готовы заплатить за курсы, которые будут вам долго эту самую интуицию нарабатывать? А смысл? Может лучше дать удочку, а рыбу сами наловите? Ну и конечно есть круг задач, которые без теории вы никогда на практике не сможете решить (хотя бы взять теорию графов). Или будете велосипед изобретать, хотя можно просто прочитать.
Поэтому обязательно читайте, обязательно теория. Это загол успеха. Но и практикуйтесь, закрепляйте знания.
Слабенько. Открываем Макконнелла и там гораздо подробнее, кейсов больше и лучше описано. В 21 веке, когда эта тема обсосана со всех сторон, с исследованиями и не только, такая статья вызывает недоумение.
угу.. так вот всё на джунах и держится. А им еще и плотют копейки и путь закрыт в ИТ. Всё кончено.
а какие-то цифры будут? или просто на интуитивном уровне `ну я видел 20%`.. `ну я наблюдаю 70/140`
откуда цифра?
откуда цифра?
откуда цифра и знания про рациональность джунов (да и людей в целом)? зачем работодателю платить копейки, тратить силы/деньги на обучение, чтобы потом начать всё заново? (жадных и отбитых не берем в расчет, видимо про них речь была). Ну или взять потом мидла, которого надо опять обучать, но уже 2х? Здесь срабатывает арбитраж (исключения не в счет): лучше платить джуну по сетке, чтобы он потом не свалил, а за повышение (даже можно сделать меньше по рынку) дорос до мидла и т.д. Проработает какое-то время, нагреет местечко и так можно тянуть и до старшего, ведущего и т.д. Терять хорошие кадры не выгодно.
Откуда вы это взяли, что джунов избегают? Работодатель не идиот. Он бы может и хотел суперведущих и бесплатно, но есть же еще и реальность: стоимость, усталость, выгорание, повышение, работа не по статусу, заменяемость. В армии же не только офицеры, кто-то и горшки должен обжигать.
К примеру, у меня в команде старшие и ведущие и я рассматриваю джунов и стажеров. И это не эффект выжившего, такого полно в командах рядом. Просто никто не готов абы кого брать, даже если ты 5 гамбургов кончил )
но если он погиб по ООМ, то значит не нарушается? он же погиб, значит партицию не слушает, значит ею завладеет после таймаута кто-то другой.
а если погиб только консьюмер, а обработка продолжается, то опять всё в ваших руках - почините консьюмер, чтобы не погибал. Или чтобы погиб, а в месте с ним и обработка, в контролируемый вами таймаут.
тут нужно рассматривать систему не в вакууме, а в реальности.
Есть такое исследование - FLP (Fischer, Lynch, Paterson). Вывод из него следующий:
В асинхронной распределённой системе с хотя бы одним ненадёжным процессом не существует детерминированного алгоритма, гарантирующего достижение консенсуса за конечное время.
То есть всё? расходимся? не занимаемся построением асинхронных, распределенных систем?
Конечно же нет. Добавляем в систему таймауты, рандомизацию и отказоустойчивость и в большинстве случаев у нас все хорошо.
Т.е. если мы берем в расчет не какую-то внешнюю не доверенную сеть, а внутреннюю (а мы ею управляем, начиная от брокеров и заканчивая клиентами), то все в наших руках.
Конечно могут быть случаи, когда "кривой" клиент не отреагировал на событие ребаланса, но что вам мешает довести его до правильных кондиций? Если вы не укладываетесь в таймауты (обычно в библиотеках это 5 минут), то что мешает его увеличить?
В этом вы правы. Для кафки очень много клиентских библиотек, где все описанное реализовано и доступно через удобные абстракции. Но всё таки, при работе с какой-то технологией, при решении каких-то особых задач, рано или поздно приходится выходить за рамки абстракций и погружаться в тонкости. Да и вообще, в целом хорошо понимать как-что работает, даже если реализовывать не придется. Надеюсь, что в этом моя статья будет полезна.
Конкретно я пишу на c#/.net. Для .net толковая библиотека - confluent.kafka.net (правда сейчас мы мигрируем на прослойку поверх grpc - об этом есть статья в блоге Озона). Conflient.kafka.net - библиотека вокруг неуправляемого кода (поверх librd) и у нее есть свои приколы и проблемы (удивляюсь, почему до сих пор нет достойной родной библиотеки).
Посоветовать язык сложно - зависит же от круга решаемых задач. Для микросервисной разработки c# весьма хорош. Мощный, выразительный, мультипарадигменный язык. С широким спектром и поддержкой фреймворков и инструментов.
соглашусь с @Derfirm. По времени занимает по разному, в зависимости от среды, ресурсов, числа консьюмеров, протокола, числа топиков, партиций и т.д. Тут надо сравнивать в одной и то же среде разные протоколы и разные сценарии. Например, eager vs coop-sticky и добавление/удаление n-консьюмеров.
в f#? try/with там нет?
честно я не сильно шарю за этот язык, но гугл говорит, что не только result.
Всякие `?` в rust позволяют же пробросить ошибку дальше? (тож в расте не силен, но первое что нагуглилось).
А в go только портянка из if'ов.
Нет, никто не говорит, что структурный подход (с try/catch) единственно правильный.
Просто обычно в языках сильно больше возможностей работы с чем либо (н.р. разные типы циклов, разные возможности обработки ошибок и т.д.).
Ибо для решения разных проблем нужны разные подходы. Серебряной пули, какгрица, не существует.
В яве хочель портянку из ифов делай, хочешь пробрасывай - лови. Хочешь любым другим способом. А стектрейс наоборот удобная штука - сразу показывает где проблема, еще и в строчку ткнет
опять "в хорошем смысле", "жизнеспособен". Сплошная вкусовщина.
Но на самом деле "Просто" - объективная характеристика. Из математики, из теории автоматов. Ее можно измерить. И, самое главное, она хорошо коррелирует с субъективной простотой (можно почитать исследования "What makes rules complext" или McCabe "Cyclomatic complexity")
Мы должны разделять простоту объективную и субъективную. Субъективная обычно основывается на знакомости. Знаешь код, знаешь шаблон - для тебя легко. Не знаешь, новое - сложно.
Берешь переписываешь - становится легко. Но упростил ли ты или просто узнал? Стало ли лучше объективно?
Автор, написав, сей опус, конечно не задумывался об этом.
А что такое "проще"?
И кто виноват? c#? А есть вообще язык, на котором можно только правильные вещи делать? А что такое правильные? А пользоваться в широком спектре им можно будет?
Это же сложно.. проще же скрипт написать на баше )
Надо сначала тему изучить, а потом лезть. Интерфейс - это контракт, а не наследование. А то еще напиши 'ой смотрите, говорят множественного наследования нет, а вон какая дичь - несколько интерфейсов'
Офигеть. Какой мощный оказывается инструмент.
Перечисленное - плюсы. Это же получается можно свои мысли выражать как хочешь. Ну а то что идиоты их выражают по идиотски - язык не виноват.
Это архитектурный паттерн. Какие определения могут быть? Это размытое понятие, с размытыми границами, некоторыми обобщенными характеристиками.
Проектирование сам по себе процесс недетерминировнный, неряшливый, с бесконечной вариативностью (ибо сложность и жизни и решаемых проблем бесконечна).
Предвзятость подтверждения. Эффект якоря.Автор упрощает и подгоняет реальность, выставляя теорию каким-то пятым колесом.
Сможете ли вы накачать мышцы без теории? скорее всего выставите себя посмешищем и объектом роликов в интернете.
Практика/опыт это наработка интуиции, когда вы можете видеть шаблоны не особо задумываясь. Решать задачи можно сказать с лёту. Это очень важно. Готовы заплатить за курсы, которые будут вам долго эту самую интуицию нарабатывать? А смысл? Может лучше дать удочку, а рыбу сами наловите?
Ну и конечно есть круг задач, которые без теории вы никогда на практике не сможете решить (хотя бы взять теорию графов). Или будете велосипед изобретать, хотя можно просто прочитать.
Поэтому обязательно читайте, обязательно теория. Это загол успеха. Но и практикуйтесь, закрепляйте знания.