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