Такой код некорректно сравнивать - его версии не эквивалентны. Одно выводит, другое форматирует. Может автор чтото другое имел ввиду? Или пример достаточно условный был. Надо пересмотреть книгу. В целом, конечно, достаточно было отделить форматирование от вывода и сделать табличный метод в статич. классе.
private String generateGuessSentence(char candidate, int count) {
Слабенько. Открываем Макконнелла и там гораздо подробнее, кейсов больше и лучше описано. В 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#? А есть вообще язык, на котором можно только правильные вещи делать? А что такое правильные? А пользоваться в широком спектре им можно будет?
Надо сначала тему изучить, а потом лезть. Интерфейс - это контракт, а не наследование. А то еще напиши 'ой смотрите, говорят множественного наследования нет, а вон какая дичь - несколько интерфейсов'
Хотя сейчас очень мощные switch/case конструкции.. их достаточно
Такой код некорректно сравнивать - его версии не эквивалентны. Одно выводит, другое форматирует. Может автор чтото другое имел ввиду? Или пример достаточно условный был. Надо пересмотреть книгу. В целом, конечно, достаточно было отделить форматирование от вывода и сделать табличный метод в статич. классе.
Это конечно тоже УГ ^
Слабенько. Открываем Макконнелла и там гораздо подробнее, кейсов больше и лучше описано. В 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#? А есть вообще язык, на котором можно только правильные вещи делать? А что такое правильные? А пользоваться в широком спектре им можно будет?
Это же сложно.. проще же скрипт написать на баше )
Надо сначала тему изучить, а потом лезть. Интерфейс - это контракт, а не наследование. А то еще напиши 'ой смотрите, говорят множественного наследования нет, а вон какая дичь - несколько интерфейсов'
Офигеть. Какой мощный оказывается инструмент.
Перечисленное - плюсы. Это же получается можно свои мысли выражать как хочешь. Ну а то что идиоты их выражают по идиотски - язык не виноват.